“0”运维时代

                                                                                                     

      最近一次公司的PR大会，对存储团队说的三点印象很深刻：
 1、某组件坏了可以不用管继续睡觉
 2、出现异常时点击一下就可立即恢复
 3、部分功能上线后可以节省很多很多钱
      
      这三个点完美的诠释了当代运维的价值与目标：高可用，高效，节约成本。我认为这就是云时代追求的”0“运维。”0“运维并不是指不需要运维，而指的是“0”负担，“0”压力，“0”成本。相反，运维将会变得越来越重要。“0”运维指的是依靠系统架构自身进行高可用和自愈能力，减少夜间及非工作日需人工干预的救火工作量；简化复杂的工作流程，提升工作的效率和质量，同时减少因重复工作量投入的人力成本；通过使用开源产品或提高资源利用率等方式，在不影响性能的情况下，减少成本的投入。对于公有云服务提供商来说，稳定性和可用性是最重要的，功能再好，性能再好，业务中断且不能快速恢复才是产品的命门，所以说，云时代拼的是运维。
 
      运维原本是没有的，规模大了，架构复杂了也就有了要运维。在中国互联网发展的初期，使用网络的人并不多，对网络并没有太多的依赖，对服务的稳定性及可用性的要求也不高，服务器的压力不大，所以服务器并不怎么需要维护，开发一并做了。而发展到现在，人们的基本生活服务都依赖互联网，加上4G和无线网络的快速发展，网民们现在基本24小时online，业务系统的架构也变得越来越复杂，后端服务器的数量都在不断增加，对支撑能力也就越来越高。人们开始不仅仅只关注产品的功能，更多的也关心产品的非功能性服务情况，随着价值的增长，运维就被独立出来了。

      运维作为与研发，测试同为产品的技术支撑，负责包括服务器上架，网络设备的设置，操作系统和运行环境的管理，应用代码部署，架构设计和部署监控，防止漏洞和攻击等等。在大型企业里运维分工的分工也很细，可以分为服务器运维，网络运维，系统运维，数据库运维，运维安全等方向。过去由于企业更多关注产品功能的实现，所以运维价值也不是很大，基本做些苦力的工作，运维就是辛苦的代名词。
 
      这几年运维成了风口上的猪，各种运维平台的初创公司，各种运维的大会，各种运维能力的PR。过去对运维的要求是安装部署，配置管理，应用发布，故障处理，健康检查，值守，而对运维的要求是高可用设计，容量管理，服务治理，用户体验提升，成本节约等等。经过多年运维的发展，人们越来越懂得运维应该怎么做才高效，智能，自动化，也有越来越多的开源工具进行支撑。比如使用Ansible等配置工作做批量的配置管理，使用Docker技术提供可读可修改可迁移的运行环境，使用Consul做自动化的服务注册和发现，使用Mesos做资源的调度管理，使用openstack做整个数据中心的管理等等。平台化，工具化，智能化，自动化，开源化一定是运维的最佳状态。从最开始的单点，到集群，到双机房，到多活，再到云，中国的IT行业已经过了技术不行，挥金如土的购买软硬件的时代。特别是初创的互联网企业，要尽可能的使用廉价的产品跑出商用产品的性能，这些靠的不是产品代码写得有多么的好，而是通过运维支撑能力让吉利跑出奔驰的性能。同时也过了堆人的时代，千万级别的服务器也许也只需要几个人的运维，而且做运维也没有过去辛苦了
。
 
      在“0”运维时代，互联网公司招聘的都是运维开发工程师，不仅要能做运维，还需要懂开发。现在对运维人员的能力要求越来越高了。过去系统软件安装都是一项重要的运维工作，而现在在容器平台上，只要基于镜像就可以在多台主机上启动容器就完成了环境的配置和软件的安全及应用的部署。过去重复复杂的运维工作都被简化了，替代而来的是对平台技术的掌握。就拿容器平台来说，需要掌握容器技术，了解各种编排工具并掌握其中一种，了解各种服务注册方案并掌握其中一种，了解各种监控方案并掌握其中一种，还需要了解运行在容器内的各种系统软件，如各种消息中间件，各种缓存等，除此以外，还需要掌握各种配置管理工作并能结合使用提升效率，还有最重要的一点，要懂得开发，能根据业务需求修改开源产品的源码。相比过去简单的架构环境，在信息爆炸的今天，运维人员也需要不断的提升自己的能力来应对新时代的发展要求。
           
      “0”运维时代的价值与目标：高可用，高效，节约成本，但是要实现起来并不是那么的容易。我们一直在谈高可用，但100%的高可用系统是不存在的，虽然可以通过专门设计来保持服务的高度可用性。比如可以使用主从方式（非对称方式），双机双工方式（互备互援），集群工作方式（多服务器互备方式）来避免单点故障造成的业务中断，但还是依然会面临着服务中断的可能性。在统计中表明，造成非计划的宕机因素中，硬件问题占40%，软件问题占30%，人为因素占20%，环境因素占10%，这么多的因素仅靠架构层的容错是不够的。一个系统的构建非常复杂，需要对基础设备层，系统软件层，应用层每一个层面的组件都进行高可用的设计。对于一个从0到有的系统，需要不断的演化才能逐步的完成所有层的高可用实现。

      对于高效的定义范围还是很广的，比如以前做批量处理需要登陆到每一台机器上操作，现在只需要运行一个远程脚本即可。又比如过去处理一个故障需要做很多的工作才能进行恢复，而现在可以根据以往的经验做一些快速恢复工具，一键工做故障恢复，进阶的还可以做一个图形化的控制面板，看到异常，只在界面上点一下就做好了处理工具。高效就是要把那些一定要人去做的工作总结出规律进行工具化或平台化提升处理的效率。比如七牛云存储先是将单盘修复时间从 3 小时提升到了 30 分钟以内，再将修复的动作根据经验进行一些自动化的处理，这样无论是修复速度还是处理过程都进行了高效化的处理。要做到高效就需要深度了解系统架构，有很强的主动意识，多年运维经验且具备开发能力的人去实现。当然，工具和平台也可以选择成熟的服务商来进行提供，但每个数据中心，每个系统都有自身的业务特点，并不是一个通用的平台就能完全配置，还是需要定制化的实现。  
 
      成本，成本，成本，重要的事情说三遍。节约成本是每个企业都在考虑的，也是技术演变的方向。从小型机换成X86,从商用到开源，中国的企业一直在寻找节约成本的方法。比如七牛提供的云存储服务，最初采用的3 副本存储系统需要投入 3 倍的存储成本。后来引入了纠删码（EC）这样的算术冗余方案，从成本角度，同样是要存储 1PB的数据，要买的存储服务器只需 3 副本存储的32.5%。节约成本很大程度上依赖的是技术的实现，比如从物理机到虚拟机到容器，资源的利用率不断的得到提升。又比如从开源到商用，或自研的一些能够节约成本的功能等，对技术能力的要求很高。
      
      习大大说要建设网络强国。互联网的发展影响着个人和企业的发展，也影响着国家的发展。这表示中国的IT个来的规模还将持续的扩展，更多的服务互联网+化。企业的IT架构也将随着科技的发展向着高可用，高效，节约成本的目标前进。《架构即未来》第一章提了一个问题：确保产品长远扩展性的关键是什么？人员，过程还是技术？答案是人，因为产品所带来的价值和出现的责任都是人为的结果，不同的人就会有不同的结果。比如说，对于不可避免的复发性故障明明可以根据经验值做一些自动化的处理，但就是没人主动或没人去推动做相应的应对措施，那就只能每次都让运维团队机械式的去救火。也许只需一个简单的脚本或几行代码，因为没人去做，就可能会需要运维人员半夜从温暖的被窝里爬起来处理。故障是不可避免的，但我们可以指对故障做一些保障性的工作，提高故障处理的效率。比如系统上线必须满足高可用要求，并进行过相应的故障演练，这样可以系统上线后规避掉一些故障；再比如对于可预见的故障场景做一些自动化的故障处理工具，根据经验值写一些脚本做一键式的恢复，避免在故障发生时还一个一个的命令执行。提高效率的方法总是有的，只看有没有人去想去做，所以运维的未来，最重要的也是人。
                     

查看原文：http://www.zoues.com/2016/10/25/0%e8%bf%90%e7%bb%b4%e6%97%b6%e4%bb%a3/