相比开发领域，运维界的发展更显沉稳谨慎。
在2016年，有一些值得运维人关注的动态：
Apache虽然依然是全球范围内使用数量第一的Web服务器；但是Nginx的热度持续升高，据调查报告显示，繁忙站点更倾向于选择Nginx，这一现象在中国尤其显着值得关注。
Google公布了Web开发新协议QUIC（Quick UDP Internet Connections），该协议使用UDP作为底层传输协议，旨在通过各种方式减少网络延迟。此外，Google已将Chrome特性在非安全站点上禁用，同时新的特性将只支持HTTPS。Chrome和Firefox所给出的数据都表明，现在全世界范围内超过一半的网页采用了HTTPS。
自动化配置管理工具常见的是Ansible、Chef、Puppet、SaltStack。其中Puppet已问世十一年，相对而言更为成熟也有广泛的平台支持；同时，Puppet连续多年做出品全球范围的DevOps年度报告。而Ansible虽然是最年轻的项目，但是它具有清晰的可读语义并且受关注度持续上涨。截止2016年12月末，Ansible在GitHub上已经拥有20397颗star，远远超出Chef（4583颗）、SaltStack（7195颗）、Puppet（4281颗）。Ansible作为后起之秀，执行SSH无须agent，对云设施支持度好，已经引起了广泛关注。
以往运维人常用的语言有shell、perl、python、ruby；但是运维开发增大了多样性，在一些公司运维开发工作需要使用如go、Node.js等。随着DevOps、SRE的概念推广和一线互联网公司的实践落地，业界已经形成一种认识——运维工作人员需要学习掌握开发能力。
不过，各家公司的情况迥异，从而运维工作内容、分工和工具选择会有不同甚至很大差异。上述的一些变化不一定会触达到每家公司，而且即使受到影响，因已选软件和语言的所带来的变化也不至于翻天覆地。
这篇2016年盘点文章，着眼于运维领域宏观的变化趋势，以期能给运维同仁带来帮助。首先，文章呈现了两个派系运维（自有云和厂商云）的具体实践和心得；随后探讨SRE概念并列举了互联网领军公司的SRE落地；最后，分析正在兴起的智能化运维并对其影响作以简单展望。
I 新内容：容器化的运维
如果说2015年是容器化的元年，那么2016年就是容器化开花结果并丰收的一年。一些互联网大厂已经大部分甚至全线容器化，而维护大规模容器集群带来了哪些变化又有哪些挑战？
没有容器之前的运维是？
每到业务高峰段（对电商而言，即促销活动）或者重大变更的时期，底层资源扩充都需要机房大规模集中性的机器上电、安装系统、部署网线，并且为各个业务划分物理机器。但是业务并不能立刻启用，为什么？打个比方，新到手的机器如同毛坯房，不经装修无法安家入住。首先需要进行水电类的硬装修，即业务版本底层的依赖包；其次才可进行软装修，即业务版本等。与业务版本相关的一切都是由业务运维部门统一处理，即便可以采用Ansible或者自研的自动部署工具提高效率，但是无法避免排队等待上线的时间花费。并且，一次次的部署也会遇到各种问题，如预期与实际环境不完全相同；即便部署成功后依然要处理后期维护，如依赖库跨版本升级。经过这些关卡，满足了某次的业务高峰，那下一次需要新的调整呢？如果要对机器重新分配和再利用，那就需要重新格式化安装。
有了容器之后呢？
一切以镜像为中心，并且资源管理方式完全不一样。
首先，保证环境的一致性。为了配合业务而进行的重大调整，不再需要传统的集中化操作（这也是最容易出问题的环节），需要分配的不再是物理机器，而是核。首先预先估算出整体需要扩充的总核数，交由机房提前统一采购部署。（以京东为例，会根据大数据分析出的业务增长率；不需要逐个统计业务需求。）然后，各个业务通过快照或者build方式构建镜像，最大程度地固化运行环境并主动提交；无需运维人员逐台机器检查各种软件版本。随后，业务人员通过自己专属镜像在控制平台的上线业务，并同意完成数据库授权等操作。对于不再使用的容器，业务人员可以在管理平台点击销毁即可释放对应的资源；而释放的资源立刻回到资源池中，无需人工操作。
其次，生产环境中秒级快速扩容，这一项已经在电商促销情形等经历了很多次业务峰值的考验，并得到了实践者的广泛肯定。当某个业务流量突增并需要资源时，运维人员不再需要找领导申请匹配的机器，也不必辛苦业务运维人员部署环境、再联系网络等等的授权。容器化可以提供横向和纵向的能力：
横向——运维人员只需在控制台页面直接申请新的资源加入业务集群，自动化完成审批授权、镜像及统一的配置中心保证环境的一致性。
纵向——针对临时压力较大的业务，容器直接在同一台机器上临时借用比自己优先级低且较空闲容器的资源，这种能力可以很好的应对秒杀类电商业务。
容器化运维的挑战是？
对于维护来说，除了后期的扩容、升级等，还有一件更重要的任务——及时发现问题并进行处理，这就涉及到了监控。容器化之后的监控工作有业务、容器及物理机三类级别，并支持业务自助式告警规则。监控层面不仅需要提供某个机器的负载情况，还需要支持某个业务的整体负载，需要用户对业务压力作以评估，并在必要情况下进行扩缩容。同时，若是监控到异常机器可以通过统一日志直接提供给业务分析问题。
容器化遇到的另一个维护难点，就是多业务混布。由于容器是共用内核，为了防止资源碎片化，集群都是业务混布。那怎么做到某个业务发生问题不影响其他业务，以及怎么对已发生问题进行及时处理就能成运维必须考虑的问题。针对这种情况，必须要提供统一的资源限制接口，能针对swap 磁盘等进行针对性的限制。一定要充分利用容器化的长处，即多副本及弹性伸缩实现的便利性。对于异常的容器，运维可以直接缩容掉并不影响整体业务，可尽快的防止单个容器可能对物理机造成的影响。容器虽然易于销毁，但要有统一日志或者本地日志备份保证问题的分析。
容器化其实并没有带来更新鲜的运维技术，它一方面是减少了运维人员大量的部署工作，另一方面是改变了一直以来的运维习惯。如果业界都认识到容器是无状态的：忙时动态扩容，闲时自动缩容，容器的异常是常态(经常是物理机导致)，那么运维的春天就不远了。
II 新模式：厂商云上的运维
2016年见证了中国IDC行业进入发展阶段，这一年，业务更加趋向多样化，对应的IT技术要求随之增多，并且难度加深。比如，高清视频直播/点播，大数据，人工智能、物联网等。中国的IDC市场规模增长率为全球平均水平的两倍。据预测，未来三年中国IDC市场增长率将保持在35%以上。Cisco公布的报告显示 ，今年全球有65%的数据中心基于云服务， 这一数字在未来三年内将升至83%，并且公有云和私有云将各自分担56%和44%的流量。这意味着企业的运维进入关联厂商云模式将成为必然的发展趋势。
那将数据中心交给云厂商之后，如果做运维呢？云计算到底是“运维”行业的终结者还是神助攻？
一个在运维领域摸爬滚打十余年，并有对于私有云、公有云甚至混合云环境运维都参与过的运维人，在这里想和大家分享一些思考。
中美运维发展分析比较
据笔者观察，欧美互联网企业对于运维的未来定义也具有微小的分歧。
以AWS为代表的“谁开发，谁运维”模式，可能是较为激进的一种。AWS的服务副总裁James Hamilton认为，运维领域中80%的问题是设计与开发问题。很显然，采用研发工程师直接运维的方式会直接解决这些问题。然而，我认为中美从业者的职业习惯还是有较大不同的。一方面，主流操作系统、编译器与开发语言大都发源自美国，美国在系统领域享有巨大的技术红利，拥有更多具有系统与运维技能背景的研发工程师；另一方面，即便是AWS的研发工程师，对于值守也感觉有较大压力。
虽然AWS采用的研发直接运维的形式教难以批量复制，但是Google SRE模式则可能被更多的国内公司逐渐采用。我想也恰恰是因为这个原因，最近关于Google SRE的讨论在互联网运维圈的讨论中是当之无愧的Top 1话题。同时我们也要看到，Google的SRE也是拥有系统与运维技能背景和意愿的开发工程师。（更多内容详见后文）
综合AWS和Google两种流派可以看到，运维领域是不会消亡的。但是，它的参与主体人群可能会迁移，它对于参与者的能力要求可能会改变。而且可以明确的看到，随着行业的成熟，对于运维从业者开发能力的要求会逐渐提高。
云计算用户的运维如何做
由于每家企业对于云计算的理解与看法并不完全相同，所以在云的使用上也存在一定差异。针对不同的云计算应用策略，运维工作肯定也会存在变化。下面将会对于主流云计算应用形式来分析运维工作的变化：
1、单一公有云用户
公有云代表性产品AWS为例，AWS的服务可以分为三类：无托管、半托管和全托管。全托管类服务我们放在后文中Serverless架构中探讨。本节只探讨无托管与半托管两类服务。
针对无托管服务，最典型的莫过于AWS EC2。EC2就相当于一台物理服务器，用户需要在EC2中部署自己的应用与中间件。针对这种场景，显然云厂商的用户还有大量运维领域的工作需要做。当然，运维工程师完全可以按照传统运维的模式在公有云上完成运维工作。但是，运维工程师想要提高效率并且对稳定性带来实际性的提升，还是有很多额外的工作空间。比如：运维工程师可以自行研发自动化运维系统，通过API和SSH与AWS EC2相集成，开展自动扩容、自动部署、配置变更、容量管理、计费管理以及监控等运维领域工作；又或者借助于AWS提供的CloudFormation、OpsWorks、CodeDeploy等管理工具更快捷的实现。基于AWS的管理工具可以帮助运维工程师便利且快速完成目标，但是自研的系统灵活性更强。
针对半托管服务，比如AWS RDS。用户并不需要去考虑操作系统层的问题。但是用户仍然需要去考虑高可用、备份、监控以及故障切换等问题。显而易见，使用半托管服务时，用户仍然需要利用公有云API来构建高可用架构、设置定期备份、实现监控与故障自动切换并实现自动扩容等功能。
2、异构公有云用户
目前国内可选用的云计算厂家众多，每家的性能、 稳定性与成本都各不相同。不少公有云的用户为了防止被某一家云计算服务商的问题严重影响自己的业务，会考虑同时使用多家云计算厂商。由于每家公有云厂商之间的服务实现和API可能会有差别，在这种情况下，用户通常会尽可能只选用类似AWS EC2这样的无托管服务。这样，用户不光更容易实现不同公有云之间的迁移，甚至可以轻松迁移到自由基础设施上。
在这种场景下，运维工程师不光需要不依赖公有云管理服务来完成单一公有云用户无托管类服务的工作，还需要实现异构云的管理。
3、混合云用户
异构云的进化版，公有云与自有基础设施的混合使用。除了将异构云管理扩展到自由基础设施外，混合云用户还可以有两个方向的进化：
a）实现应用能够跨越自由基础设施和公有云的弹性部署与扩容。此方向的用户通常会采用Docker等容器方案。
b）在自有数据中心实现一套与公有云API相同的基础设施；或者在公有云与自由基础设施之上实现一层混合云PaaS或API，使之可以自适应公有云和自有基础设施。
无论哪种方向，运维工程师都有非常多的工作需要做。
4、Serverless架构用户
Serverless架构是这几年公有云领域蹿升的热门技术。虽然名词听起来很新，但其概念并不是突然提出来的。我个人认为，Serverless架构其实是一种更为抽象化的PaaS服务。既然并不算全新的领域，所以Serverless架构的基础设施落地自然也就不是什么难事。随着AWS将要在国内引入Lambda服务和国内公有云厂商纷纷推出Lambda服务，Serverless架构在基础设施与服务上已经实现了落地。
然而基础设施落地不代表客户一定会买账。由于Serverless架构比类AppEngine类PaaS服务更为抽象，国内开发者对其接受程度还需要时间来验证。可以肯定的是，最为活跃又乐于尝试新技术的开发者肯定已经开始尝试Serverless架构了，但是企业为了业务长远发展是否会在近一两年就考虑Serverless架构目前恐怕还不能下结论。总之，我个人观点，虽然基础设施已经落地，但Serverless架构真正被企业大规模使用可能还需要时间。
由于Serverless架构的高抽象化，完全将云计算与应用代码直接连接，也许确实不太需要运维这个工种甚至领域。但是，Serverless架构对于开发者也是存在进入成本，现在的运维工程师完全可以通过学习在未来转向为Serverless架构开发工程师。
云时代下，运维岗位会怎样？
通过上文的分析与总结，我们可以推断未来运维领域的三种可能：
像AWS那样趋向岗位统一；
像Google那样岗位独立；
Serverless架构环境下用户无需考虑运维领域，岗位仅剩开发工程师。
其中前两种对运维岗位能力要求趋同。
无论沿着哪个发展方向，开发与工程能力都是当前运维工程师需要注重发展的首要能力。或许未来不需要运维工程师，但你还可以做开发工程师啊！
III 新主张：从SRE谈开来
SRE的概念前几年业界就有提及，但是当时的资料信息并不是很多，只道是“网站稳定工程师，以保障稳定为主”。今年，Google SRE团队将经验沉淀落笔成书；同时，笔者近两年有幸与在海外从事SRE的专家进行交流，再结合自己多年的互联网运维经历。整理思路之后，将个人理解和观察分享如下。
SRE由Google提出
首先抛个结论出来，SRE的目标不是Operation，而是Engineering，是一个是“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位，为了保证达成这个目标，Google强制约定了50%的工作法则，SRE至少保证50%的时间是在做自动化开发的工作上，实际这个比例可能会更高，所以SRE运维的工作内容是低于50%的。
我个人觉得更准确的理解应该是，Google压根就没把SRE定义为运维（Operation）的岗位，运维（Operation）这个岗位或工作内容更多的指的是原来传统运维模式下SA的职责描述。
Google团队在书中第一章就分析了从SA和SRE两个不同的视角来看待Google线上系统的区别，正是因为SA模式下遇到了很多无法解决的问题，才引入了SRE这样的软件工程岗位，而引入这个岗位的目标就是为了消除掉原来SA运维模式下的问题、矛盾和冲突。
也正是Google换了一个思路，从另外一个维度来解决运维的问题，才把运维做到了另一个境界。下面是文中的几个关于SRE的描述，大家可以一起理解下看看。
By design, it is crucial that SRE teams are focused on engineering.
SRE模型成功的关键在于对工程的关注
SRE is what happens when you ask a software engineer to design an operations team.
SRE就是让软件工程师来设计一个新型运维团队的结果
另外，还有一个很有意思的地方，就是整本书中提到Operation（运维）的地方其实并不多，而且大多以Operation load、Operation overload、Traditional/Manual/Toil/Repetitive operation works等词汇出现，理解一下，是不是跟上面的推断也很契合。
SRE虽然没有被给以直接的定义，但是Google SRE给出了职责描述：
In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).
SRE需要负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。（这里先不做过多的解读，后面详细描述。）
Google SRE 人力技能模型大致分为两类：50-60%为SWE，即软件工程师；余下40-50%还要至少对Unix内核和底层网络（1-3层）非常精通才可以。从这里也可以大致推断出，Google SRE的技能要求是非常高的，SWE只是基础条件。从技能模型上，按照Google的标准，原来传统的SA或NE这样运维角色根本无法胜任Google SRE的岗位，势必要进行非常艰难的转型。此外，除了软件开发、内核和网络等硬性的知识技能，还需要具备产品sense、沟通协作能力、规范制定意识等软技能，因此SRE门槛确实很高。
那么DevOps和SRE的关系是什么呢？在《SRE:Google运维解密》一书中，谷歌团队认为DevOps所倡导的与SRE的核心思想和实践经验相符合，并且认为SRE是DevOps模型在Google的具体实践。
大厂都怎样落地高端运维
雅虎：作为互联网业界的鼻祖与技术的翘楚，硅谷很多优秀的技术经验都源自雅虎。在雅虎，有个运维的岗位叫PE（Product Engineer），早期能够走上这个岗位的工程师都是在开发团队承担业务架构师或资深SWE这样的角色，因为一个应用或业务上线后，对应用最熟悉的就是这批人，他们能够很好的跟产品人员协作起来，传递应用在线上运行的状况。同样，产品人员一旦发现问题与PE可以顺畅地交流，交流完还可以直接改代码上线。在这种运作模式下，产品、开发、运维协作非常最高效，这种模式被一直延续下来。因此，PE的岗位职能和角色与SRE是基本相同的。
阿里：2005年，阿里收购了雅虎中国以后，雅虎中国的工程师也被合并进来。阿里应用运维岗位也叫PE，这个岗位就是传承着雅虎的运维文化和模式而来，据说是现在阿里合伙人之一刘振飞09年当时在创建技术保障部时成立了PE的团队。但是，这支PE团队更多的就是偏应用运维了，绝大部分人是不具备SWE能力的，这一点也是受限于当时国内整个技术能力的水平，不可能一下招到这么多的原来雅虎的那种PE工程师。（不过这并不是大问题，将在后文中分析为什么。）
Facebook：熟悉FB的同学可能也不陌生，FB的应用运维岗位也叫PE。师承何处笔者并没有找到第一手资料，前段时间通过与FB的一个工程师交流，发现FB的PE与阿里模式相近更偏应用运维一些。
LinkedIn：很有幸今年12月2日的ArchSummit大会上笔者负责的运维专题邀请到了LinkedIn SRE团队主管，并在会议期间深入讨论了的关于SRE团队的组建和分工职责等。在LinkedIn以应用运维为主，SRE的职责跟阿里PE和FB PE相似。
Google的SRE必须具备很强的SWE能力，所以可以自行开发很多的自动化和稳定性的模块。但是这种人才很稀缺，对于一般的公司很难招到这样的人或者组成这样的一支团队，所以按照Google的模式基本是玩不转的，那应该怎么办呢？答案就是：依靠团队的力量：单个人搞不定的事情，可以靠团队中具备不同能力的人协作，共同达成SRE的职责和目标。根据笔者对FB、LinkedIn和国内的绝大多数公司的了解，这种方式实际也是大多数公司所采用的方式。目前对于运维团队的基本组成模式：
系统运维：SA、网络工程师和IDC工程师。
应用运维：国内大多叫应用运维，国外大多都定义为SRE或PE（国内同样，如阿里叫PE，滴滴、小米、美团等叫SRE）。
技术支持：以阿里为例，主要是问题跟踪和一些流程组织及闭关跟踪的事情：故障复盘、改进Action执行跟踪等。其它很多公司可能由QA会承担一部分这样的职责。这个部门相应地国外叫NOC，虽然不参与问题的直接解决，但是对于问题的推进，尤其是对于线上运维规范性的监督作用非常大。
工具&平台开发：自动化、监控、持续集成&发布和稳定性平台开发。
数据库DBA：DBA有可能也会是独立团队。
运维安全：对线上网络、系统和应用安全负责。大多是独立团队，但是即使独立，跟运维团队都是紧密协作的。
还是以阿里为例，阿里之前的技术保障部简称就叫SRE，是PE应用运维、工具开发、技术支持、DBA、安全、系统运维的组合起来的一个大的部门，非常典型的SRE团队作战的优秀实践。但是从今年开始，运作模式也发生了很大的变化，特别是应用运维PE这个岗位，后面会详细讲到。同时，后面我们再提到SRE就不是一个单独的岗位了，而是一个团队或者一种能力，那接下来重点说一下应用运维和工具平台开发的岗位。
两类运维岗位的思考
(1) 应用运维需求上升
随着互联网业务的高速发展，到目前为止已经诞生出太多的大大小小的互联网公司，各个公司都越来越需要SRE或PE（应用运维）这样的角色。例如，在Facebook、PE对开发的比例目标是 1:30；这个比例很有挑战（包括目前Facebook自己），大多公司可能还在1：100，甚至更低。但是从趋势上，可以说明应用运维这个岗位的重要性越来越大，同时也越来越受到重视，对于做运维的小伙伴无疑是个很好的信号。
目前在国内，我们的应用运维岗位还是多以线上的部署、发布、监控和问题的处理为主，其中有很多都还是以手工操作的方式为主，按照之前我们的分析，SRE的目标不是做这些事情的，或者说不应该是以这些事情为主才对，所以大家可以想一下我们的应用运维在实际日常工作中，是不是以这些事情为主？甚至把这些事情当做了常态？如果是这样，按照SRE的标准就不是合格的SRE。
对于应用运维笔者认为首先要做到意识上的转变，（尽可能将工作提炼并转化成脚本需求）（即产品需求分析能力），同时还要进行标准和规范的制定（SLI、SLA、SLO）与执行（将标准规范和需求功能固化到软件平台）。这一系列的专业工作还需要软性技能：怎样将需求转化成产品层面需求并表达出来，怎样同业务开发同学沟通制定标准和规范等等。
（2）工具平台（运维开发）为实现依赖
这个角色，实际就是SRE中SWE的能力职责了，要能够准确的理解应用运维同学的需求，是否能够开发出满足实际运维场景的平台，直接依赖于工具平台同学的能力。
这里涉及到怎样理解产品设计进行精确开发，如何将孤立产品整合便于使用。同时工具平台铜须还需要锻炼学习系统、网络和应用运维的一些技能，因为通过这块能力的提升，工具开发同学实际是在转向Google标准中的SRE。
小结
Google定义的SRE的角色如果单兵作战能力达不到，就通过团队协作来达成。这也是基本除了Google之外的互联网公司所采取的一种运维模式。
在具体落地时，可以将SRE的落地拆分成不同的职责岗位和团队协作。应用运维应该要能够制定和执行各种稳定性的标准和规范，能够将人工和重复的工作提炼成需求，并把这些需求能够转化成产品设计文档，准确的传递到工具平台团队，确保各方理解一致，从而能够使得各种自动化的工具平台落地。各大公司对这个应用运维的角色越来越重视，在笔者看来，应用运维的好坏直接决定了系统的稳定。
SRE所涵盖的工作内容和职责，其实在国内外的互联网公司也都在做，比如自动化、持续集成和发布、监控等等，对于标准、规范和流程上，每个公司也都有自己的一套适合自己公司业务和技术特点的体系。SRE不神秘，Google在做的事情，业内公司其实也在做，从体系上一些大厂也已经非常的完善，但是技术能力上的差距，是我们努力的方向。
IV 新发展：当运维遇上智能
2016年可以说是人工智能的元年，各行各业都在讨论智能化，都在尝试将智能在各自领域落地。运维是个传统意义中“劳动密集型”行业，公司们希望降低人工运维风险，同时又希望提升监控质量和日志分析能力在部分运维事务中形成闭环，这也就是为什么笔者认为运维对智能化的诉求其实更有现实意义。
其实，人工智能技术已经开始在运维领域小试身手，如大数据SRE团队会使用各种机器学习算法加持大数据计算引擎的助力，以期获得自动化解决方案。在笔者看来，运维生态有了另外一种可能，转向智能化运维时代。
我所理解的智能化运维
智能化运维是一套智能体系，它强调了从监控到分析决策再到执行的整个过程的无人化甚至超人化，突出的是系统的自治能力和预知能力。
智能化运维主要需要做到监控智能化、分析智能化和执行智能化。
监控智能化相较于传统监控，突出的是监控数据的深度和多样性。例如从读数到读图的增强，从当下判断到全周期比较，从静态阀值到动态加速率，从系统基础指标到定义标准运维metric，一步步将监控从被动接受到主动预知方向推进。
执行智能化是对解决各式各样的运维模式下人工执行的沉淀。今天仍然有很大一部分的运维事务需要由人去处理，如何构建一个灵活的运维事务沉淀框架是一件非常有令人激动的工作。如同蒸汽时代对人类发展的意义，智能执行是所有智能化的基础和前提。
分析智能化是最终替代和超越人的思维的解决方案，也必然是我们智能运维的发展核心。智能化分析的实现离不开各种人工智能技术的应用，当谷歌的AlphaGo大胜人类的那刻，人工智能不再属于科幻，而是切切实实的未来。当然广义上的人工智能不是我们今天所立刻能够达到的，在比较长的一段时间里，我们能够企及的是在特定任务中机器的能力可以匹敌人的能力，甚至更好。这种能力是在特定业务场景下的狭义人工智能，也是我们未来几年努力的主要方向。
新的能力需求
谈到智能化运维的具体落地，笔者预测未来在资源规划、故障处理以及监控预警这几个业务方向将会有实质性的突破，这也意味着对机器学习和数据挖掘人才的需求将是以后的大势所趋，IT企业在运维自动化和智能化将会有倾向的投入。
在笔者看来，新时代的优秀运维人，应该学习基础系统、业务产品，具备优秀编码能力，并将容器化、大数据、机器学习算法结合到业务场景中。
小结
“运维工作”在今天需要被重新定义，传统意义的运维重视被富裕繁重但是低价值的标签。笔者认为运维分为四个层次：“人工、自动、智能、智慧”，当前的运维行业可以说是处在一个人工、自动、智能互相交叠的时期。
智能化运维的价值在于：降低“传统运维”事务的时间；增大高附加值运维事务的投入；使得运维工作可以向上关联业务发展，向下关联基础建设，对整个公司长期发展将起到举足轻重的作用。2017年会是运维智能化百花齐放的中兴之年：通过技术、数据提升人力资源、财务资源、基础建设等方面的效率，笔者认为运维将会在整个公司生态中拥有更大的话语权，期待智能化时期业界发掘出真正的运维价值。
第三十八届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：pingxiaoli
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
