运维大牛万字自述：道尽十多年血泪史与转型自救路

与一个行业大牛的朋友交流时，在听到他年轻时在思科的一些关于将工作方法升华为方法论，比如“监、管、控”、“新网点”理念，并推动整个行业建设时为之一震。这个触动让我有了让自己的运维知识体系建设做第一次飞跃的打算，即如何将知识体系通过一个主线串起来。

关于这个主线，找过一些朋友做了交流，比如“风险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。由于自己主要身处一线运维团队，所以选了“可扩展性”的主线，接下来打算根据这条主线，不断完善知识体系，目标是体系化的整理知识体系，主要从组织、流程、工具的可持续整合。

以下内容，主要是对运维整体的概览，讲讲对运维的认识，以及一些转型理念思考。

一、运维不简单

前阵子，跟一个项目经理沟通能否提前半天将变更申请提交过来时，这位项目经理很不理解地问我：“你们运维不就是在生产环境部署个程序这么简单的工作吗？你们又不懂程序，评审不出什么吧？”

运维多年，对运维的这类认识听过很多，它反映了企业里不同的组织团队对运维的认识往往仅限于一些简单操作性的工作，比如生产应用系统在故障时的重启、应用变更时敲敲命令、平时增删改查数据，或者是办公室和电有关的所有软硬件的使用问题等等。

那么如何理解运维呢？百度百科对运维的解释为：企业IT部门采用相关的方法、手段、技术、制度、流程和文档等，对IT软硬运行环境（软件环境、网络环境等）、IT业务系统和IT运维人员进行的综合管理。从百度百科的解释看，运维岗位需要一个综合性的技术与管理能力，需要掌握大量的方法论与技术栈。

运维狭义“运维技术与资源”可以定义为“监、管、控”，技术与资源主要是支撑运维/运营的质量、效率、成本的平衡。以下简单摘录了运维的一些能力要求：

运维规范的落地：以ITIL、ISO20000、ITSS.1等方法论，结合外部监管及内部规范的落地；监管机构的要求落地：理解、快速响应、落地监管机构的管理要求；基本保障：配置、监控、应用发布、资源扩容、事件、问题等；基础能力：网络、服务器、操作系统、数据库、中间件、JVM、应用等基本使用与调优；业务服务能力：SLA，服务台、业务咨询、维护、经验库、等支持能力；可用性管理能力：巡检、业务系统连续性、可用性，基础架构及应用系统的高可用、备件冗余资源；风险、安全管理能力：操作、审计、监管风险，漏洞、攻击管控；故障管理能力：事件、问题管理水平与能力；持续交付能力：应用变更、基础资源、办公服务交付能力；主动优化能力：架构优化、性能响应效率、客户体验等；应急演练：架构高可用、突发事件、业务故障的架构、方案、文档、人员熟练程度等；业务支撑：数据维护、数据提取、参数维护等；运行分析能力：容量、性能、可用性分析等；运营能力：促进业务痛点的发现与解决、客户及业务业务体验等；成本控制：更好地评估人力、硬件、带宽、软件，节省成本；运维开发：运维自动化工具的建设，运维开发能力的培养；其它

不同的企业需要运维的能力会有不同的扩展，同进上述能力要求每一点扩散出来都将是一个复杂的技术栈，比如“基础能力”中的Linux操作系统的内核关系图（摘自互联网，图1.1），或再深入一些关于MySQL优化（摘自互联网，图1.2），需要运维人员对技术能力深度的要求。

图1.1

图1.2

讲到这，肯定会有人说上述的技术栈的能力要求，通常是由于某个运维组织的仍处于专家式运维，自动化程度不够高导致。

的确，理论上所有运维操作性、命令的工作都可以整合为经验，并通过自动化落地实现，现在互联网企业对外都宣称自动化在运维工作覆盖面很高，己经开始迈向智能化，AIOps，甚至提出了NoOps的解决方案。

关于这些互联网企业的自动化对日常运维工作真实的覆盖面暂时无法考究，但以我的经验看，至少金融企业的自动化覆盖面还有很长的路要走，且肯定还会很大一部分工作很难自动化，毕竟工作类型太多，在有限的投入上只能集中力气去做投入产出比更高的运维自动化。这里再以一个运维工具思维导图（图1.3）简单列示一些常规的运维操作，可以看出其实很难有一套能解决所有运维操作的工具平台。

图1.3

所以我觉得，随着业务要求越来越高、规模越来越大、监管要求越来越高，纵使外部如何宣称自动化、智能化对运维人员经验、技术、管理能力替代，金融企业内的运维还需要认清实际情况，结合企业的整体战略定位，强调运维团队在运维管理与技术能力的广度与深度，再有侧重、有先后的实现自动化水平。

在未来一段时间里，金融企业的运维岗位仍是一个复杂的、综合性技能的工作岗位。

二、运维之痛

1、组织之痛

前面讲过，在企业内部其它团队对运维的认识通常是简单操作，出故障时才会找的团队，随着信息技术的发展与业务的发展，运维组织痛点越来越明显，企业内对运维组织的不满的声音越来越多，反思一下原因，分外部客观因素和内部因素。

1）外部客观因素

在当前大数据时代，金融企业的运维面临业务规模的不断扩大，业务竞争越来越激烈，监管要求越来越高，数据中心的规模也越来越高，大量新技术、开源架构的引入取代了传统稳定的系统架构等等因素影响。

运维组织的角色

绝大部分运维组织都是一个成本部门，企业对运维组织的重视程度通常不如开发组织，更不用说是前台业务部门。这方面造成了运维部门的规模通常增长很慢，以Google为例，在《Google SRE运维解密》一书中提到，由于Google的数据中心规模急剧扩大，系统越来越复杂，而运维人员规模又跟不上，所以他们的运维组织采用组建SRE的运维开发团队实现自救。

业务对运维服务质量的要求