关于这篇文章,源自于很久之前学习产品时的一个认知。

大家都知道"自动化运维"其实是一个很广泛的概念,其概念的不确定性在于"自动化",有争议的地方在于"自动化"到什么程度,才能称之为"自动化运维"。



运维工程师：

         运维工程师(Operations)在国内又称为运维开发工程师(Devops)，在国外称为 SRE（Site Reliability Engineering）。负责维护并确保整个服务的高可用性，同时不断优化系统架构、提升部署效率、优化资源利用率提高整体的ROI.

        运维工程师面对的最大挑战是大规模集群的管理问题，如何管理好几十万台服务器上的服务，同时保障服务的高可用性，是运维工程师面临的最大挑战。

        在一些规模较大的公司(比如：Google、FaceBook、百度、阿里、腾讯等)，运维工程师和系统管理员是有一定的区别：

        系统管理员：主要负责机房网络、服务器等硬件基础设施的运行和维护。

        运维工程师：主要负责管理并维护在运行在海量服务器上的软件服务。



以上说明源自于百度百科词条，从该词条所描述的运维工程师的主要工作为:  在成千上万甚至几十万台的服务器集群中,保障服务器的高可用性。



自动化：

           自动化（Automation）是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。自动化技术广泛用于工业、农业、军事、科学研究、交通运输、商业、医疗、服务和家庭等方面。采用自动化技术不仅可以把人从繁重的体力劳动、部分脑力劳动以及恶劣、危险的工作环境中解放出来，而且能扩展人的器官功能，极大地提高劳动生产率，增强人类认识世界和改造世界的能力。因此，自动化是工业、农业、国防和科学技术现代化的重要条件和显著标志。



以上说明源自于百度百科词条,从该词条所描述的自动化的概念为: 自动化是指在没有人或者较少人的直接参与下，完成一系列的工作要求。



那么，将运维与自动化结合起来看的结果是什么？ 自动化运维: 即将运维工程师的工作在不需要或者只需要少量工程师的干预下,能够完成工作要求，保障服务器的高可用性。



怎样进行自动化运维？



关于运维的状态(即演变过程):



一、人工化操作: 

       当互联网刚刚兴起的时候,企业的规模并不大。一个很明显状态是: 浏览互联网的网民少、企业的规模不大、服务器数量稀少(1~20)、可用于(浏览/交互)的(网站/BBS)数量稀少，从而导致了企业中通常是一人身担多职，可能同时担任(软件工程师/运维工程师/网络管理员)等职位。由于用户群体的稀少，服务器数量的低量，大部分工作都通过人工来完成，也不会有太大的工作量耗费大量的人力来完成。



二、操作脚本化: 

        当互联网渐渐兴起，用户群体增大，企业所需要服务的用户群体也会随之变多。此时由于服务器数量的增多(50~200)，负责服务器维护的工作量便大量上升。由于工作量的成倍增长，这时候担任维护服务器的管理员会发现大量的工作占用了非常多的时间，甚至于会让工作时间之外的私人时间也被占用，每天需要处理大量重复性的问题。此时已经严重影响到了私人生活,于是为了将自身从无止境的重复性劳动中解脱出来，开始为一些重复性的工作制定一个标准的处理方案，然后将这种标准的处理方案分解成一步一步执行的步骤，然后使用技术手段(shell/python/php/perl/)将这些步骤一步一步的实现，然后集合到一起成为可用于处理重复性工作的脚本。通过脚本可以便捷的处理之前需要花费大量时间来处理的重复性工作。这里实现了 "脚本自动化",即某些问题不需要人工或者只需要少量人工干预即可完成。



三、脚本工具化: 

       此时，互联网的发展开始走入正轨、用户群体开始膨胀。此时，企业需要服务的用户群体也会进一步增大。相对的，服务器数量又会增多(200~500)，此时采用脚本来解决问题已经陷入了瓶颈，每天可能会有大量的服务器出现这样那样的问题。工程师开始疲于奔命，在一台又一台机器上运行脚本，修复系统业务环境。这时候放佛又回到以前，每天需要大量的时间来处理大量重复问题(ex: disk full),这些问题往往都有一个共同点: 出现次数相对频繁，并且处理方法大同小异。这时候,将这些出现的问题也分门别类归结成大同小异的处理脚本。当出现对应问题时，登陆到对应的服务器上执行处理对应的处理脚本即可解决问题，但是由于服务器数量的日益增多，同时出现问题的服务器的数量也会直线上升。此时如果继续重复以前的做法，手动 登陆到每一台服务器上去执行脚本，也会产生很大的工作量。此时，如果能在一台服务器上控制所有的服务器，然后通过该服务器对相同症状的服务器群批量执行修复脚本,就能节约出大量的时间。这时候就出现各种能够批量操作服务器的工具，如expect、sshpass、puppet、cchef、saltstack等，借助这些工具来批量执行脚本来完成工作。此时，通过批量管理工具实现了只需要少量人工干预就能完成工作，即将脚本集成到工具中，实现脚本工具化，从而达到工具自动化。



四、工具平台化： 

      什么是平台？

             平台将平时复杂的事情简单化，手动的工作自动化，无序的工作规范化，提高运维的质量和运维的效率，以此来提高整个企业的IT服务水平、服务质量，拥有极强的可维护性、可扩展性、可伸缩性等优秀特点。

      使用平台能做什么？

            平台可以集成大量的工具、可以应对大部分的业务场景、可以让没有技术能力/专业知识的人员进行专业操作等。

      为什么要将工具平台化？ 

            平台拥有可视化操作，将工具集成到平台中，可以在可视化的平台中通过说明来完成一系列需要专业知识支撑的复杂操作，可以通过描述让没有专业知识/专业知识不够的人员进行标准的专业化操作、可以解放大量的人工操作、可以降低学习成本、可以提高运维效率、可以提升系统安全性/稳定性等。

     

五、平台产品化

       什么是产品？

            产品是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。产品一般可以分为五个层次，即核产品、基本产品、期望产品、附件产品、潜在产品。核心产品是指整体产品提供给购买者的直接利益和效用；基本产品即使核心产品的宏观化；期望产品是指顾客在购买产品时，一般会期望得到的一组特性或条件；附件产品是指超过顾客期望的产品；潜在产品指产品或开发物在未来可能产生的改进和变革。

        为什么要将平台产品化？

           产品是“一组将输入转化为输出的相互关联或相互作用的活动”的结果，平台是作为技术的衍生，为了满足相对应的业务场景而创造出来。

           平台的核心需求是将"复杂的事情简单化，手动的工作自动化，无序的工作规范化."

           产品的核心要素是"给购买者带来基本利益和效用",即 "满足使用者的购买期望，丰富使用者的期望价值"

           为什么要将平台产品化？:

                  平台是一种解决方案，我们需要给这种解决方案附加上一系列的价值，或使用一系列的思想来修饰解决方法，使大部分人接受这种解决方案、认同我们的方法思想，从而完成平台的自我价值的提升，即平台产品化。

                      为什么要将平台产品化？ 

                              古人云: 达则兼济天下,穷则独善其身。 

                           产品是一种自我期望，产品期望可用于提升自我价值、可用于输出企业文化、可用于提升企业价值。

                       产品是一种经济期望，可用于换取利益、可用于创造价值、可用于增加附加价值

六、产品生态化   

      ？