云时代的运维正是不折不扣的架构师
1、引言
上学那会，每当作文中引用到张良这个典故，总喜欢用 “运筹帷幄之中，决胜千里之外” 来赞美张良雄才大略，指挥若定，现在还让我用的话，我会把这句话送给运维同学。
2013年左右，一朋友在某某国企做运维，除了拆机、装机、做系统、协助领导上网站、打印资料..... 工作相对软件公司的运维还是相当清闲，可以愉快的喝茶聊天发呆，偶尔也可以学点自己想学的技术充实自己，直到有一次，领导办公室的灯泡坏了，让它去修下，他感觉以前干的活跟电脑沾点关系，而修灯泡只跟电有关系，次日提交离职报告，发誓去远方追梦。
2、传统运维职责
传统模式下的运维一般要承担很多工作：物理机管理、应用部署、网络架构、dba等等，运维往往是个多面手，因为什么都干，所以看起来更像是一个打杂人员，定位比较尴尬，往往不能得到公司领导的重视。
关于薪资，相对来说运维人员的工资没有程序员的工资高，毕竟工作强度不是一个量级。
关于技术，对于运维人员来说，并不需要深入理解某某编程语言，掌握某某核心技术，出了问题，只要肯看日志，愿意谷歌，几乎可以解决80%的问题。
关于程序员和运维的关系，很多人把运维调侃成一个 “背锅” 角色，我觉得一般情况下让运维背锅并不容易，背锅这种事情还跟运维人员的自身技术有关系，只要技术运用娴熟，运维人员有理有据的甩锅也是常规操作。
类比于工业时代，传统运维人员只需能够驾驶着别人制造的列车前进就行了。听了这句话你也就不难理解为什么我们传统的运维人员甩锅是常规操作了。
而现代化的运维不要求你会开车，更多是参与制造汽车，最大程度上让车自动化、智能化。如何实现？且听下文继续分析。
3、去人肉运维化。
运维人员更重要的是搭建和管理自动化平台，内部开发团队可以依赖我们的工具，但是不能依赖我们的劳动力。当然搭建一套人见人爱、花见花开的平台绝非偶然，初期的话，可以借助开源项目，过去有PaaS，现在我们可以借助谷歌Kubernetes、Prometheus、Rancher等开源工具，尽快完成运维平台的搭建，搭建完成不算完，像Kubernetes本身也会有一些自己的短板，像有状态应用支持有限，可能要基于Operator自己开发，对于AI行业常用GPU更是支持太弱，我们需要不断深入研究和探索工具，总之搭建这套自动化运维平台对内一定能把运维有限的精力运用到有价值的事情上面，对外一定能够满足开发团队发布和部署的需求。
4、谁开发、谁部署、谁监控
传统做法通常是，开发人员开发完成、提交测试、测试通过、一个邮件或者内部群通知运维人员某天晚上11点以后开始部署，开发和测试人员在工位焦灼等待验证功能是否正常。运维人员一封邮件发给所有干系人 “已经部署完毕、请验证” 。开发一看 "点哪那不行" 一封邮件通知运维，赶快把日志发过来......
传统模式下几乎所有公司的开发人员和运维人员都会有固有的冲突，且不管最后是谁的责任，这个过程最大问题就是开发人员不关心部署的具体细节，而运维人员不关心应用的具体实现细节，这就导致了运维和开发之间的代沟，详尽的文档可以解决一部分问题；但最终还是开发人员自己最了解自己的系统。这当然跟公司组织架构也有关系，通常都是研发一个团队、运维一个团队，甚至于独立的产品线都依赖于集中式运维团队。
那么如果开发人员自己开发自己部署，运维人员难道啥都不用干了吗（天天研究技术多爽啊）？自动化平台搭建完成就可以裁掉80%？其实不然，举个例子，让程序员在linux下部署个主从模式Mysql，打听下自己身边的程序员，不通过磕磕绊绊的搜索有几个可以高效完成的；有人要说，这种工作不能让运维帮忙完成啊，不会又回到从前了吧！
那么如果通过运维人员加入开发团队呢？
一般情况下，一个产品团队应该能够自给自足，独立完成产品的部署和交付；但是产品开发初期，让开发人员独立完成系统基础环境和产品运行环境的搭建不是特别现实，这时我们可以在产品团队组建初期加入运维，让运维扮演跟开发人员同样角色，参与团队内部事务。
当团队成员都在参与需求识别、任务估算、软件开发的时候，团队中的运维人员需要在这个过程中识别开发团队的活动，做好数据库驱动设计、表结构设计、单机部署还是集群部署、是否存在有状态服务、比如不经常变动数据可能适合存储到关系型数据库，查询频繁的数据更适合存储到内存数据库，这些都需要运维人员的参与和设计，并且能够提前做好部署和发布的准备；
当开发团队需要部署产品需要基础环境时，运维人员和开发人员一定要密切配合或者通过交叉培训的方式完成环境的搭建和部署，这个过程后期可能需要开发人员独立完成；
完成上述工作之后，运维人员可以像开发人员一样，把上述的运维过程转化为自动化代码，使整个过程更广泛和可靠的运行。比如一些人为的过程，借助Jenkins打包工具，通过编写脚本，自动把文档和软件包分发到各自服务器；从而为产品团队输出了自动化部署脚本、sql优化过程、监控使用等工作成果。
说到这里很多人要说对于普通中小型公司，运维是很珍贵的资源，可能就那么一撮人，根本不够用，这时可以采取当工作完成到自动化这个阶段运维就逐渐淡出产品开发团队，根据个人能力，以同样的形式融入另外一个或者多个团队。当然运维人员的组织还在原来集中式运维部门。
5、总结
通过对比传统运维和云时代运维，描述了运维和开发一体化的理念和方法。这个过程要求运维人员有更强的统筹和架构设计能力。这些能力，对于云时代的运维不正是必备的吗？
推荐阅读：
Kubernetes排障指南
从零搭建Kubernetes下的nignx和tomcat
Kubernetes中如何使用ClusterDNS进行服务发现？
Kubernetes入门培训（内含PPT）
从Ice到Kubernetes容器技术，微服务架构经历了什么？
原创不易，随手关注或者”在看“，诚挚感谢！