曾说过，运维开发是IT运维的未来发展趋向之一，但具体啥叫“运维开发”？

一、说文解字

第一个层面，浅层意义，是指“运维工具的开发”。曾经确实如此，例如在HP（Service Manager）和IBM（Tivoli）等国外企业级解决方案为王的时代。那时，实施一套运维工具集，就像在实施SAP的ERP，全过程从咨询到落地实施，不但复杂得很，而且各位运维管理人员、运维工程师就像小学生那样好学（bei dong），毕竟领导说了，上运维系统就要走“固化-僵化-优化”的正路，但理想与现实的鸿沟，还是如此鸿沟：

• 不强迫不用：一堆运维专业工程师，用系统就像在“做作业”，有种智慧被污辱的赶脚，哪还有积极主动性哉，于是大家都推一步做一步（不考核不做）；
• 
  
• 用了自己也改不动：这些大工具，做到这么有普适性，肯定用得不就手，偶尔有积极主动性时，工具又改不动（原厂没啥开放性可言）；
• 
  
• 叫人也改不动：成熟套装工具在建设之初，肯定先做一大轮所谓“需求调研分析”。当运维工程师讲干口水、咨询顾问们拍拍屁股之后，一堆书名号报告倒是如期形成了，但运维工具却还是那个样子，运维工程师的想法很多都没有落实（“报国无门”）。
  

表象千千万万，但如此易于失败的原因究竟何在？此刻，柯南突然降临：

【解】：IT运维工具的受众和其他MIS系统的用户不同，他们自己本来就是IT人员，是最懂IT运维管理和技术的从业者，而不是不懂IT的业务人员（况且现在各行各业的业务人员，也越来越懂IT了）。所以，IT运维工具的开发实施方法论，不能照搬其他业务系统的方法论。

针对新时代的“运维开发”含义，个人认为，应该是“有运维特色的开发”、“有运维特色的开发”、“有运维特色的开发”（重要事情重复三次）。是开发，但又不是普通的开发，这是我们所要高举的旗帜：

1、无名无利的开发：作为底线保障的部分，运维开发怎么说都不可能在聚光灯之下。在腾讯，估计做微信、游戏的，怎样都比做蓝鲸和织云的要光鲜，至少在相亲时向美女介绍自己工作，不用解释一听就明白。光天化日之下，除了超人是底裤外穿之外，就没有见过第二个。

（图： 采自网络图片 | 艰苦奋斗，一直是运维的优良传统）

2、要求全栈的开发：就像相声《报菜名》的节目一样，运维工具要涉及的软硬件类别多不胜数，关键最痛苦的还不在于多，而在于“隔行如隔山”，每种东西的脾气都各不相同，要能做到数据打通的“大同世界”，必须祭出神秘全栈武器——“攞你命3000”：

（图：采自网络图片 | 每一样武器都独当一面，但加起来就……？）

3、要求可DIY的开发：运维工具的使用者都是天天窝在机房“搞机（基）”的暗黑神秘高手、段数高，肯定不满足于一体成型的工具，而且未来的自动化和智能化时代，运维更需要大量的脚本或者算法模型，这些都是在实际工作中按需灵活编制的（无法提前在系统需求调研分析阶段就全部梳理完毕）。现在好多高大上的IT名词，都要冠个“软件定义的XX”来装潢自己，也就是意味着，工具要有持续的延伸性和可塑性，运维工程师可以不断对它赋能，这样才能赢取他们的青睐。

（图：采自网络图片 | 向客户展示DIY神技，甜过初恋）

除了第一个要求是精神层面之外，其余两点，都是技术层面。但很明显，传统的“烟囱式”运维工具系统，已无法再满足要求。硬是要针对传统系统再去优化完善，恐也会积重难返、事倍功半，唯有大刀阔斧，想起IT人最常用的两大招数（重启、重装），“华山一条路”，全部推到重来，用全新架构来完成“有运维特色的开发”任务，或许是一条可行的路径。

基于过去的经验教训，结合对业界动态的粗浅学习，本人在运维开发方法论方面，有一些想法，不成熟，但尽可抛砖求玉，以供各位方家大神讪笑。总体而言，可概括为“一简、两化两微、三同步、四全”：

（图：某ppt大神的贡献）

• 一简：简约，而不简单；不用多解释了，这句话早已被智能手机的广告洗脑。既然运维工具，无论是大的平台系统，还是小的应用脚本，主要目的都是工具，既然是工具，就要追求实用，删繁就简，直接对接功能核心。一方面，别将普通汽车的中控台设计成大飞机的控制室这么复杂，同时简约不代表简陋和缺失，也不能将大飞机的控制室按钮强行砍成普通汽车的中控台。总之，除了演示场景或者汇报场景之外，一律以最终需求为依归、以解决核心痛点为宗旨。
• 
  
• 两化两微：（1）两化，指的是自动化+智能化，意思是要搞运维工具，目标就应该直接指向自动化和智能化，传统的流程类功能（规范化）不是说不做，而是说不是重点难点了，如果连普通的规范化功能都做不好，那就算了，回家去“采菊东篱下”吧。（2）两微，指的是微小开发团队+微服务架构，一定要用上敏捷的研发模式，不能再用传统瀑布式过程了，迭代周期太长，另外，一定要用上灵活可扩展的技术架构，不能再做烟囱系统出来（去系统化），谨慎拥抱新技术潮流（前提是开发团队要hold得住微服务架构）。
• 
  
• 三同步：是我认为的运维开发方法论核心。因为有运维特色的开发与传统MIS不同，受众自己需要DIY，所以切不可做出一体成型的工具出来。于是，我将工具划分为“平台-应用-脚本”，这三者是神圣三位一体的，三者即可同步推进、又相互交织渗透，是我心中的“铁三角”。
• 
  
  

（1）厚平台：运维平台一定要做大做强，包括CMDB、流程引擎、自动化作业编排、数据处理等等，都应该在平台层得以科学合理地解决。当然，各运维开发组织可以根据自身条件和策略，选择不同的构建平台路线：既可以采购成熟商用平台（如腾讯蓝鲸、优云等），也可以自己利用开源世界的代码来研发/整合（如Ansible与Zabbix的串联），甚至不采购不自研，直接用社区版的平台（如直接用Ansible，不改了，只做配置实施），丰俭由人。总之，因为这个平台层的能力，决定了所有“上层建筑”的成长上限，具有关键性的影响，所以选择的机会成本很高，技术债需要做好记录和分析。

（2）轻应用：应用是介于平台和脚本中间的一种形态，在研发速度上，要相对较快，同时要兼顾一定的非功能性需求，可以独立自成体系，也可以依托于平台的开发框架研发（需要平台能提供开发框架及环境），一般来说，研发应用的子团队要更为微小，用的技术架构要更为轻量级。通过研发及实施各种、各类运维应用，经实践检验，如果应用具有一定的成熟度以及可复用前景的话，最终还可以整合入平台层，丰富平台层的能力，但这个是水到渠成的过程，在运维人员构思应用的时候，无需担负太多的整体考虑，需要轻装上阵，单独体系的小应用并不丢人，并非每把小刀都需要整合到瑞士军刀中。

（3）灵脚本：我们要面对这么多复杂的运维对象和场景，(i)对于自动化场景而言，要采集并控制这么底层的设备或软件平台，脚本是怎样都绕不开的存在，语言就包括shell+python+go+c……（一堆神兽飘过），还未完，协议包括ipmi+snmp……（又一堆神兽飘过），没有两三把vi功力的神侠在，自动化就是空谈；

（ii）对于智能化场景而言，一堆数学算法，什么分类+聚类+关联+自学习……（还是一堆神兽飘过），如数学建模竞赛一样，不弄些算法分析模型，谈何智能化？这些脚本级的工作，可以是实验性质的，没有所谓，最紧要的是要以最快的速度完成任务，非功能性需求（如交互友好性等方面）可以先晾在一边暂不考虑。

当然这些脚本，可以依赖于平台运行，也可以依赖于应用运行，也可以直接运行，看情况而定。最后，脚本可以慢慢越做越大变成应用或者整合入平台，都是极可能发生的场景。

• 四全：个人认为，要做好运维开发工作，必须贯彻“四全方针”：（1）全栈，针对对象而言；（2）全过程，针对系统阶段而言，例如运维要参与开发阶段，就必须要有DevOps的工具支撑；（3）全息展示，需要全面提升可视化的广度和深度，但要注意，这里不是说要用美工来雕琢界面效果，要的数据信息的有效表达；（4）全员参与，没有运维工程师可以独善其身，不参与任何运维工具的研发设计，若只安静地做运维工具的使用者，那是没有前途的。
  

啰嗦了这么多，似乎说明了，有运维特色的开发是这么难做、要这么花心思和资源，但为啥还要去做？我们是雷锋吗？靠堆人头，一样能做日常运维工作，何必呢？no zuo no die，万一运维开发工作做得不好，失败了，那不是更糟糕？

是时候，祭出我自己瞎扯的“运维四化图”出来了。

其实，从Lv2“标准化+可视化”阶段起，运维工具系统的重要性已经不言而喻，但还是可以依靠外部成熟套装产品，由第三方公司完成运维开发工作，其中部分问题已在本文开篇说过，此阶段另外一个最大的问题是，脱离不了“人肉运维”的痛苦——运维效率低。于是，大家都想要跃迁到Lv3-Lv4的自动化和智能化阶段，而这种跃迁，却不能单靠外力。如果自身运维团队不转型、不自觉投身运维开发的洪流，即使外部有多不胜数的运维平台，连具体脚本都不会写，这样的团队，乖乖地继续呆在原地吧，终有一天将被历史的大浪淹没。

简言之，运维开发不算风光（是与业务系统开发相比较而言的），也很难，但此神功却实实在在是改变人肉运维搬砖的必要条件。团队自身拥有运维开发能力，才有希望跃迁到Lv3-Lv4，才有可能像某电商所称的，6人管理1000+的机器。

更简言之，运维是背锅侠，英雄世界有两位也是背锅侠，其一是忍者神龟，其二是美国队长。能自主可控掌握运维开发能力的，才能去做美国队长。因为，美国队长背上的锅，除了可以背之外，还可以潇洒地甩，锅也能成为武器。

曾说过，运维开发是IT运维的未来发展趋向之一，但具体啥叫“运维开发”？

一、说文解字

第一个层面，浅层意义，是指“运维工具的开发”。曾经确实如此，例如在HP（Service Manager）和IBM（Tivoli）等国外企业级解决方案为王的时代。那时，实施一套运维工具集，就像在实施SAP的ERP，全过程从咨询到落地实施，不但复杂得很，而且各位运维管理人员、运维工程师就像小学生那样好学（bei dong），毕竟领导说了，上运维系统就要走“固化-僵化-优化”的正路，但理想与现实的鸿沟，还是如此鸿沟：

• 不强迫不用：一堆运维专业工程师，用系统就像在“做作业”，有种智慧被污辱的赶脚，哪还有积极主动性哉，于是大家都推一步做一步（不考核不做）；
• 
  
• 用了自己也改不动：这些大工具，做到这么有普适性，肯定用得不就手，偶尔有积极主动性时，工具又改不动（原厂没啥开放性可言）；
• 
  
• 叫人也改不动：成熟套装工具在建设之初，肯定先做一大轮所谓“需求调研分析”。当运维工程师讲干口水、咨询顾问们拍拍屁股之后，一堆书名号报告倒是如期形成了，但运维工具却还是那个样子，运维工程师的想法很多都没有落实（“报国无门”）。
  

表象千千万万，但如此易于失败的原因究竟何在？此刻，柯南突然降临：

【解】：IT运维工具的受众和其他MIS系统的用户不同，他们自己本来就是IT人员，是最懂IT运维管理和技术的从业者，而不是不懂IT的业务人员（况且现在各行各业的业务人员，也越来越懂IT了）。所以，IT运维工具的开发实施方法论，不能照搬其他业务系统的方法论。

针对新时代的“运维开发”含义，个人认为，应该是“有运维特色的开发”、“有运维特色的开发”、“有运维特色的开发”（重要事情重复三次）。是开发，但又不是普通的开发，这是我们所要高举的旗帜：

1、无名无利的开发：作为底线保障的部分，运维开发怎么说都不可能在聚光灯之下。在腾讯，估计做微信、游戏的，怎样都比做蓝鲸和织云的要光鲜，至少在相亲时向美女介绍自己工作，不用解释一听就明白。光天化日之下，除了超人是底裤外穿之外，就没有见过第二个。

（图： 采自网络图片 | 艰苦奋斗，一直是运维的优良传统）

2、要求全栈的开发：就像相声《报菜名》的节目一样，运维工具要涉及的软硬件类别多不胜数，关键最痛苦的还不在于多，而在于“隔行如隔山”，每种东西的脾气都各不相同，要能做到数据打通的“大同世界”，必须祭出神秘全栈武器——“攞你命3000”：

（图：采自网络图片 | 每一样武器都独当一面，但加起来就……？）

3、要求可DIY的开发：运维工具的使用者都是天天窝在机房“搞机（基）”的暗黑神秘高手、段数高，肯定不满足于一体成型的工具，而且未来的自动化和智能化时代，运维更需要大量的脚本或者算法模型，这些都是在实际工作中按需灵活编制的（无法提前在系统需求调研分析阶段就全部梳理完毕）。现在好多高大上的IT名词，都要冠个“软件定义的XX”来装潢自己，也就是意味着，工具要有持续的延伸性和可塑性，运维工程师可以不断对它赋能，这样才能赢取他们的青睐。

（图：采自网络图片 | 向客户展示DIY神技，甜过初恋）

除了第一个要求是精神层面之外，其余两点，都是技术层面。但很明显，传统的“烟囱式”运维工具系统，已无法再满足要求。硬是要针对传统系统再去优化完善，恐也会积重难返、事倍功半，唯有大刀阔斧，想起IT人最常用的两大招数（重启、重装），“华山一条路”，全部推到重来，用全新架构来完成“有运维特色的开发”任务，或许是一条可行的路径。

基于过去的经验教训，结合对业界动态的粗浅学习，本人在运维开发方法论方面，有一些想法，不成熟，但尽可抛砖求玉，以供各位方家大神讪笑。总体而言，可概括为“一简、两化两微、三同步、四全”：

（图：某ppt大神的贡献）

• 一简：简约，而不简单；不用多解释了，这句话早已被智能手机的广告洗脑。既然运维工具，无论是大的平台系统，还是小的应用脚本，主要目的都是工具，既然是工具，就要追求实用，删繁就简，直接对接功能核心。一方面，别将普通汽车的中控台设计成大飞机的控制室这么复杂，同时简约不代表简陋和缺失，也不能将大飞机的控制室按钮强行砍成普通汽车的中控台。总之，除了演示场景或者汇报场景之外，一律以最终需求为依归、以解决核心痛点为宗旨。
• 
  
• 两化两微：（1）两化，指的是自动化+智能化，意思是要搞运维工具，目标就应该直接指向自动化和智能化，传统的流程类功能（规范化）不是说不做，而是说不是重点难点了，如果连普通的规范化功能都做不好，那就算了，回家去“采菊东篱下”吧。（2）两微，指的是微小开发团队+微服务架构，一定要用上敏捷的研发模式，不能再用传统瀑布式过程了，迭代周期太长，另外，一定要用上灵活可扩展的技术架构，不能再做烟囱系统出来（去系统化），谨慎拥抱新技术潮流（前提是开发团队要hold得住微服务架构）。
• 
  
• 三同步：是我认为的运维开发方法论核心。因为有运维特色的开发与传统MIS不同，受众自己需要DIY，所以切不可做出一体成型的工具出来。于是，我将工具划分为“平台-应用-脚本”，这三者是神圣三位一体的，三者即可同步推进、又相互交织渗透，是我心中的“铁三角”。
• 
  
  

（1）厚平台：运维平台一定要做大做强，包括CMDB、流程引擎、自动化作业编排、数据处理等等，都应该在平台层得以科学合理地解决。当然，各运维开发组织可以根据自身条件和策略，选择不同的构建平台路线：既可以采购成熟商用平台（如腾讯蓝鲸、优云等），也可以自己利用开源世界的代码来研发/整合（如Ansible与Zabbix的串联），甚至不采购不自研，直接用社区版的平台（如直接用Ansible，不改了，只做配置实施），丰俭由人。总之，因为这个平台层的能力，决定了所有“上层建筑”的成长上限，具有关键性的影响，所以选择的机会成本很高，技术债需要做好记录和分析。

（2）轻应用：应用是介于平台和脚本中间的一种形态，在研发速度上，要相对较快，同时要兼顾一定的非功能性需求，可以独立自成体系，也可以依托于平台的开发框架研发（需要平台能提供开发框架及环境），一般来说，研发应用的子团队要更为微小，用的技术架构要更为轻量级。通过研发及实施各种、各类运维应用，经实践检验，如果应用具有一定的成熟度以及可复用前景的话，最终还可以整合入平台层，丰富平台层的能力，但这个是水到渠成的过程，在运维人员构思应用的时候，无需担负太多的整体考虑，需要轻装上阵，单独体系的小应用并不丢人，并非每把小刀都需要整合到瑞士军刀中。

（3）灵脚本：我们要面对这么多复杂的运维对象和场景，(i)对于自动化场景而言，要采集并控制这么底层的设备或软件平台，脚本是怎样都绕不开的存在，语言就包括shell+python+go+c……（一堆神兽飘过），还未完，协议包括ipmi+snmp……（又一堆神兽飘过），没有两三把vi功力的神侠在，自动化就是空谈；

（ii）对于智能化场景而言，一堆数学算法，什么分类+聚类+关联+自学习……（还是一堆神兽飘过），如数学建模竞赛一样，不弄些算法分析模型，谈何智能化？这些脚本级的工作，可以是实验性质的，没有所谓，最紧要的是要以最快的速度完成任务，非功能性需求（如交互友好性等方面）可以先晾在一边暂不考虑。

当然这些脚本，可以依赖于平台运行，也可以依赖于应用运行，也可以直接运行，看情况而定。最后，脚本可以慢慢越做越大变成应用或者整合入平台，都是极可能发生的场景。

• 四全：个人认为，要做好运维开发工作，必须贯彻“四全方针”：（1）全栈，针对对象而言；（2）全过程，针对系统阶段而言，例如运维要参与开发阶段，就必须要有DevOps的工具支撑；（3）全息展示，需要全面提升可视化的广度和深度，但要注意，这里不是说要用美工来雕琢界面效果，要的数据信息的有效表达；（4）全员参与，没有运维工程师可以独善其身，不参与任何运维工具的研发设计，若只安静地做运维工具的使用者，那是没有前途的。
  

啰嗦了这么多，似乎说明了，有运维特色的开发是这么难做、要这么花心思和资源，但为啥还要去做？我们是雷锋吗？靠堆人头，一样能做日常运维工作，何必呢？no zuo no die，万一运维开发工作做得不好，失败了，那不是更糟糕？

是时候，祭出我自己瞎扯的“运维四化图”出来了。

其实，从Lv2“标准化+可视化”阶段起，运维工具系统的重要性已经不言而喻，但还是可以依靠外部成熟套装产品，由第三方公司完成运维开发工作，其中部分问题已在本文开篇说过，此阶段另外一个最大的问题是，脱离不了“人肉运维”的痛苦——运维效率低。于是，大家都想要跃迁到Lv3-Lv4的自动化和智能化阶段，而这种跃迁，却不能单靠外力。如果自身运维团队不转型、不自觉投身运维开发的洪流，即使外部有多不胜数的运维平台，连具体脚本都不会写，这样的团队，乖乖地继续呆在原地吧，终有一天将被历史的大浪淹没。

简言之，运维开发不算风光（是与业务系统开发相比较而言的），也很难，但此神功却实实在在是改变人肉运维搬砖的必要条件。团队自身拥有运维开发能力，才有希望跃迁到Lv3-Lv4，才有可能像某电商所称的，6人管理1000+的机器。

更简言之，运维是背锅侠，英雄世界有两位也是背锅侠，其一是忍者神龟，其二是美国队长。能自主可控掌握运维开发能力的，才能去做美国队长。因为，美国队长背上的锅，除了可以背之外，还可以潇洒地甩，锅也能成为武器。