我在M2公司做架构之运维体系构建

M2公司和我当初所在的创业公司都有一个共同特点，那就是没有运维，所以就由我这个具有运维经验的开发来兼任。

这些年也写了关于运维相关的不少文章，我最早的写博客是在博客园写的，写了上百篇关于运维技术相关的文章，感兴趣的朋友可点击下面链接访问:
145篇Linux文章

上面是术方面，下面是道方面的，文章如下:
我对运维的思考

下面我将谈谈我在实际中是如何构建运维体系的。

一、什么是运维？

运维这个词，拆分后，意思为运行和维护，即一个软件系统的运行和维护。但实际中远远不止这么简单。

二、运维所要求的技能有哪些？

在我看来技能分为通用型和专门型。
通用型技能无论是在哪家公司，要求是必须掌握的。在我看来运维的通用型技能可分为如下(八大运维通用型技能):

• 一定的软硬件知识、计算机网络知识、操作系统知识等；
• 会重装系统(Linux或Windows，有的公司是采用Linux，有的公司是Windows Server)；
• 具备基础通用型软件的安装和配置(Nginx、Redis、MySQL、Apache、Mongodb、Memcache、Tomcat、Zookeeper等，实际远不止这些)；
• 掌握常用的Linux命令；
• 文档编写能力；
• 能够编写一般的Shell脚本；
• 软技能(独立分析和解决问题能力、沟通能力、抗压能力)；
• 强烈的安全意识。

通用型技能无论在哪家公司都能用的到，这些通用型技能，也可以叫基础技能。

而专门型技能需结合特定公司的特定业务场景,例如:

• 推行自动化运维，需掌握Python、Gitlib、Jenkins、Maven或Gradle、SonarQube、Ansible等工具安装和配置；
• 公有云运维，根据公司采用的是哪家公有云，需要有哪家公有云的运维经验(例如阿里云、腾讯云、华为云、天翼云等)；
• 自动化监控，需掌握Zabbix、Cacti、Prometheus、Nagios等常用监控工具安装和配置；
• K8s运维，需掌熟练掌握K8s、Docker等技术；
• Hadoop运维，需熟练掌握Hadoop技术；
• Oracle运维，需熟练掌握Oracle技术；
• MySQL运维，需熟练掌握MySQL技术。

三、衡量一个优秀运维人员的标准有哪些？

1.朋友A认为，衡量优秀运维人员的标准如下

• 网站服务7x24小时年复一年不间断；
• 网站数据不丢失或者即便丢失也能快速恢复找回；
• 为公司省钱，提高工作效率。

2.朋友B认为，衡量优秀运维人员的标准如下:

• 学会”偷懒”，用自动化的技术解放人力，提高工作的效率；
• 良好的沟通能力、分析问题能力、解决问题能力；
• 基础扎实；
• 跨部门协作能力；
• 安全意识扎根于脑；
• 责任心。

3.在我看来，衡量优秀运维人员的标准如下:

在我看来应该包含前面两位朋友所说的，但不够系统全面，这里我引用一本书里面的来概括优秀运维人员的标准，这本书叫《IT运维之道》，作者叫李鹏，从事IT运维工作20多年。

优秀运维人员的标准可归纳为如下:

• 有目的、有计划地做事；
• 注重规范性和完整性；
• 高效率和高质量；
• 亲和性和系统性；
• 懂业务和善思考；
• 善于客户沟通；
• 善于团队协作；
• 基本功扎实；
• 自律性强。

四、IT运维四件要事

引用《IT运维之道》这本书的部分内容阐述相关的理论知识。

• 按运维原则做事；
• 掌握服务平衡；
• 落实整体运维；
• 贯穿服务流程。

1.IT运维服务的原则

• 事前:讲计划、重承诺；
• 事中:讲规范、重控制、有反馈；
• 事后:重效率、能应急、有保障。

(1)事前:讲计划、重承诺

想在运维过程重轻轻松松，又能做到点上，就要重视实现的计划，计划来源于和客户达成的承诺或领导的命令，在整个运维过程中，计划是整个工作流程的核心，年度计划(依据服务承诺制定)又是计划中的龙头，按照计划先行的原则，依据本年度工作计划制定分项工作计划(如巡检计划、监控计划、培训计划等)和时间维度计划(季度工作计划、月度工作计划等)，并遵流程，按计划进行实施和保障。所以，工作计划是真正运维具体工作的龙头，它是围绕实现服务承诺而制定的，各分项工作计划(如巡检计划、监控计划、培训计划等)和时间维度计划(季度工作计划、月度工作计划等)，都应以确保实现服务承诺为前提。其中，现场巡检计划是运维工作计划的核心，因为现场巡检工作具有重要的作用和意义，通过现场巡检能够发现系统薄弱环节、关键业务节点、存在的隐患，尤其是对制定应急预案及备品备件计划至关重要。当然，写得再完美得方案如果不做就等于纸上谈兵、水中之月，所以，计划执行应是重点，企业得成功很多时候是赢在执行，运维体系能否严格按照工作计划执行是运维服务效果能否达标得关键因素之一。当然，如果计划发生变化，那么如何执行也应进行相应更新和变动，以适应工作计划需要。在运维执行中，应严格按照流程规范开展运维，并注重控制以降低运维风险。针对运维执行情况，应定期向用户进行反馈。不过计划得粗细、时间跨度要依据项目和公司情况而定。

要讲工作计划的执行效果及运维结果与服务承诺进行对比，对比的结果应作为改进工作计划的输入，确保对用户的承诺能够达成。在此过程中，运维人员将根据工作需要定期或不定期将运维工作情况向用户进行反馈与汇报，让用户全面了解整个系统运行情况及运维工作情况。因此，总结起来可以说:运维工作执行来源于计划，受控于流程，输出于反馈，更新于实践。

获得用户的信任是长期、稳定、深入开展运维工作的基础和前提，而要获得用户的信任，很重要的一点就是讲求信任，即重承诺。重承诺是IT运维服务商向用户提出具体的运维服务承诺，并认真做好运维工作，确保各项运维指标达到标准，从而获得用户的信任，让用户放心。用户对运维工作的信任需要长期、耐心、深入地开展工作。

简单来说，对于用户不要轻易许诺，而一旦许诺，就要做到。具体体现在以下方面:

• a.事先和用户约定服务级别协议(SLA)，对于所承诺的服务级别目标应严格履行。
• b.对于给用户所做的书面或口头承诺，包括提供的资源、提供的方案、应给与的回复，都应在约定的时间内，按约定的要求予以提供或实现。
• c.向用户进行承诺后要认真执行相应的工作任务，确保服务承诺可以达成，重点是给用户的各种计划，应按计划安排予以执行，确需调整应提前向用户进行说明以调整计划。
• d.对用户做出的书面服务承诺必须达成，当预判对用户的承诺在既定的时间内可能无法达到时，应提前向用户解释，并提出补救措施，以尽量达到服务承诺的标准。
• e.及时向用户汇报各项服务承诺达成的情况，让用户了解我们对运维承诺的重视执行力。

(2)事中:讲规范、重控制、有反馈

没有规矩，不成方圆。运维工作尤其需要注重规范性，讲规范就是按照既定的工作流程、礼仪、制度、要求等开展工作，这会让用户感受到我们的运维服务是透明的，符合科学流程的。这项工作的价值还体现出服务的一致性，无论用户在何时向任何运维工程师提出运维服务要求，他们均享受品质一致的运维服务，获得良好的服务体验。

讲规范的好处可归纳为如下:

• 对于所有运维人员，能够按照统一的服务规范开展工作，使运维参与者均能形成优良的服务意识，以确保运维服务质量。
• 清晰的工作流程能够使用户感受运维服务的专业性、一贯性。
• 有效的执行服务流程能够确保其中的每个角色职责清晰，进而提高运维效率。
• 统一的服务礼仪能够体现运维工作者的良好形象，规范的文档编写能够体现运维人员的专业素养，这均有利于用户满意度的提升。

如何做到讲规范，重点做好以下工作:

• 按照运维管理体系制定完备的运维工作流程，按照流程的角色定义，明确各角色在流程中的职责。
• 通过培训让全体运维人员熟悉并掌握运维工作规范的要求，通过沟通让用户充分理解运维工作流程的执行效果对用户的重要性。
• 运维服务者通过日常工作认真落实各项运维工作流程与规范，借助运维服务管理平台记录执行的过程与结果。
• 运维管理者通过定期汇总分析常见故障和突发事件量及事件完成质量，了解流程规范执行的落实效果，并在此效果基础上持续改进。

重控制是为了控制运维服务质量达到运维服务承诺的要求而开展的工作。主要涉及两个方面:一是确保运维服务目标按要求达成，二是有效控制运维服务过程中的系统风险。在运维过程中，若不注重控制，将很难保证运维服务结果达到约定的要求，而且，有可能发生一些影响较为恶劣的重大事故，比如业务中断、数据丢失等。因此，在运维过程中注重控制，将有效规避风险，保障运维服务质量。

重控制包括关键流程节点控制、操作痕迹化管理、变更控制、发布控制、定期回顾并出具服务质量报告等。具体措施包括:

• 按照运维服务的特点梳理运维服务流程的关键节点，将关键节点的日常运维工作文档化。
• 运维过程要体现痕迹化管理，所有事件、变更、发布等环节的处理细节均应被完整记录下来，作为质量跟踪的依据。
• 对于系统变更，均应受控于变更管理流程；所有变更均应充分评估风险，并在实施前经过严格测试，制定好回退机制，确保风险可控的情况下进行变更实施；若因故变更失败，亦能通过回退机制恢复服务。
• 对于系统发布，均应受控于发布管理流程和变更管理流程；所有发布均应提前进行严格测试，制定好回退机制，确保风险可控的情况下进行变更实施。在应用部署发布前制定测试方案及运维保障实施方案。
• 定期开展事件流程的回顾会议，对于存在的问题或风险进行分析并提出改进措施，在下一个周期内改善服务质量、规避系统风险，以有效控制整体运维服务质量。
• 内部严格按照”运维报告机制”进行内部报告和审核，以对相关情况纳入跟踪控制范畴，按照统一口径进行处理。
• 在运维实施过程重定期(如每月或每个季度)进行流程执行过程与结果的检查与回顾对于存在的问题或风险进行分析并提出改进措施，可在下一个周期内改善服务质量、规避系统风险，以有效控制整体运维服务质量。

与用户建立良好的沟通是做好运维服务的关键。有反馈主要指运维服务者向用户及时反馈信息。有反馈就是在做好运维服务的基础上，让用户及时了解我们的工作情况，适当的运维信息反馈给用户是必不可少的。用户作为运维服务的消费者也是最终受益者，如果对运维工作不了解或了解不透彻，从某种意义上说是用户的损失，也是运维服务者对运维服务质量不够重视的体现。

向用户进行必要的反馈，能达到以下目的:

• a.对于用户的关切点，包括系统运行状况、潜在风险情况、运维工作情况等，定期通过书面方式报告给用户，这充分尊重了用户的知情权，并且可让用户全面了解系统整体情况及运维情况，进而对运维产生信任感。
• b.对于重大事件的处理进展，定时向用户进行报告，有利于缓解用户的紧张和急躁情绪，避免运维工作陷入被动。
• c.对于用户提出的需求，按时予以反馈，能让用户感到自己的建议和意见获得足够的重视，从而建立良好的工作关系。

做好运维过程重的沟通反馈主要包含如下几个方面:

• a.定期向用户出具运维工作情况报告(如周报、月报、年报)，向用户展现系统运行情况、潜在风险分析、隐患发现情况、故障受理情况、其他各类服务情况及运维服务建议等。
• b.在处理重大事件过程中，按与用户约定的频次主动(如半小时1次)向用户报告故障的排查情况、处理进展和预计恢复时长等。
• c.对于各项需要向用户进行反馈的信息，应事前制定”运维报告机制”，运维服务者都应该按照”运维报告机制”进行内部报告，并有各级管理人员审核，从而可以将相关情况纳入内部质量跟踪控制范畴。同时经过报告和审核的内容要按照报告机制及时向用户做出口头或书面等报告。
• d.对于用户提出的各类咨询或服务请求，应在处理过程中及时向用户报告处理进展或解决建议，积极主动和用户进行沟通交流。

(3)事后:重效率、能应急、有保障

一般来说系统一旦发生故障，用户往往希望能够在最短时间内解决，对运维效率提出了很高的要求，尽量减少对业务造成的时间或金钱上的损失。重效率是指在处理各类故障和咨询服务时，我们始终做到快速响应、迅速处理。这需要运维服务者能够做到及时响应需求、快速定位故障、安全排除故障。运维服务者如果能够满足将重效率和有反馈有效地加以运用，可获得用户的充分信赖。

• a.运维服务者均应树立”想用户之所想，急用户之所急”的观念，将用户对解决问题的迫切性放在首要位置。
• b.运维管理者应该按照科学化的理念测算各类故障级别的平均恢复时长，安排运维工程师对每一个级别的故障排除方案进行反复演练，一旦故障发生能够熟练地处理故障，快速解决问题，稳妥恢复业务。
• c.运维质量管理部门通过日常事件处理的服务恢复时长检查运维事件处理是否能够达到快速响应和处理的要求。
• d.建立IT服务管理体系，定期回顾事件处理效率在哪些方面存在改进的空间，定期发起持续改进。

对于系统突发的故障，尤其是影响程度高的故障，若能快速应急并迅速解决，就会在用户和我们之间建立充分的信任关系，若所有突发故障均能迅速解决，将使用户对我们产生信赖感，即在信任的基础上形成依赖。因此，整个运维服务团队的应急保障能力至关重要。

为了提现应急保障能力，可采取以下措施。

• a.建立应急预案，提前做好各类预判与准备，必要时定期对应急预案进行演练，包括不同类型事件的应急保障团队、保障服务方式等，确保一旦突发故障真实发生能够有条不紊地按照预案进行应急响应和处理。
• b.配备一定的应急服务装备，如处理故障的必备工具、排除故障的必须备件、恢复系统的必备软件、3G无线网卡、精确检测仪器等，IT运维专家首先是能够依靠技术手段提升应急保障能力的专家。
• c.对于信息化系统中包含硬件设备的用户，我们应该建议用户储备必要的备品、备件和备机，一旦突发硬件故障且短时间内无法修复时，能够利用备品备件先行顶替故障设备，从而尽快恢复业务。

运维服务的效果体现为”有保障”，运维队伍给用户的感觉简单来说就是:召之即来，来之能战，战之必胜，从而让用户对系统放心、对运维放心。如果运维工作是有保障的，就能消除用户的后顾之忧。

要做到有保障，可采取以下措施:

• a.通过网络互动服务、电话服务热线，现场服务等多种运维服务途径让用户随时随地有问题都能够找到我们。
• b.如果IT系统较大或较复杂，运维服务商内部建立起一线、二线、三线的运维梯队，二线对一线进行支持，三线对二线进行支持；系统开发商、设备供应商都属于我们的三线支持，必要时能够给予二线足够的支持与保障，确保整个运维工作是有保障的。如果IT系统较小或较简单，运维服务商不一定需要建立完备的一线、二线、三线队伍，但需要在岗位职责中包含相应的职责，从而确保运维工作流程是闭环的。
• c.运维服务商内部有完善的软硬件支撑环境，包括:IT服务管理平台、电话呼叫系统、网上培训平台、全套运维模拟环境、运维协同办公系统等。
• d.在重要时期，比如业务高峰期或重点节假日期间制定重点保障预案，严格按照保障预案执行，并在结束时向用户提交重点保障完成情况报告。

2.掌握服务平衡

• 主动服务:服务者发起运维服务；
• 受理服务:用户提出运维需求。

(1)主动服务

主动服务是服务者主动为用户提供一系列运维服务，其目的是为系统提供防患于未然的维护保养服务，使得系统长期处于一个健康稳定的状态。主动服务是确保信息化系统安全、高效、平稳运作的有效手段。主动服务还可以让用户获得更好的服务体验，更好地了解系统的运行状态和未来需要配备的备机及备件资源等，从而使用户对服务者产生信赖感。主动服务的形式包括:向用户提供服务计划、对IT系统定期巡检、设计必要的应急预案。主动服务的工作内容包括:远程监控、现场巡检、技术培训、服务报告、问卷调查等。主动服务完成的效果可以从策略制定、计划实施、服务评价三个方面进行评价。

(2)受理服务

受理服务是用户在发生故障时向运维服务者提出服务需求并获得运维服务的过程，其目的是在信息化系统意外发生故障时得到快速有效的解决，从而减小对业务的影响。受理服务包括受理各类用户电话请求(故障请求、服务请求、咨询请求等)、远程请求和现场服务请求。受理服务标准包含三方面:受理服务分类标准、受理服务处理规范、受理服务效率要求。这些工作将由服务提供商和用户共同确认，双方彼此都接受与认可，作为日后执行受理服务的目标与要求。

a.受理服务分类标准

对于用户提出的各类请求，即故障、服务、咨询及变更等请求(统称为”受理服务事件”)。

b.受理服务处理规范

受理服务处理规范包括响应时间要求、电话作业规范、事件处理流程三部分，其中:响应时间要求是针对用户拨入电话的响应速度，将用户的等待时间限定在一定范围内；电话作业规范主要约定了电话用语，以使用户感到整个受理服务过程是热情、专业、规范的；事件处理流程规定了事件从受理开始到受理结束应经历的过程，以确保每一事件的服务质量。

c.受理服务效率要求

受理服务的效率要求包括目标恢复时间要求与目标解决时间要求，依据受理服务分类与事件类型确定每一类、每一级事件的目标恢复时间与目标解决时间。

3.落实整体运维

• 软件支撑系统；
• 应用系统；
• 计算机硬件设备；
• 机房与环境。

(1)软件支撑系统的运维

软件支撑系统是指为应用软件运行条件的软件环境包括操作系统、编译程序、数据库管理系统、中间件、各种高级语言等。

主要运维工作是:提供日常例行检查、故障排除、系统软件升级、定期巡检、数据库性能调优、系统与中间件部署、系统软件维护培训等运维服务。

(2)应用系统的运维

应用系统是指为特定用途所开发并可在生产环境执行的一个或多个应用程序，以及和程序一起产生的数据信息。

应用系统运维主要包括:日常性维护、纠错性维护、适应性维护、完善性维护、操作系指导和技术培训、数据完整性维护及数据分析等。

(3)计算机硬件设备的运维

计算机硬件设备是指计算机系统中由电子、机械和光电元件等组成的各种物理装置的总称。

计算机硬件设备的运维包括对PC电脑、平板电脑、服务器、存储设备、网络交换机以及其他计算机控制设备提供定期巡检、定期保养、故障诊断与排除以及备件的更换等运维服务。

(4)机房及环境的运维

计算机机房普遍指的是电信、网通、移动、双线、电力以及政府或者企业等存放服务器、为用户以及员工提供IT服务的地方。

机房及环境的运维主要针对机房中比较重要的设施(如配电、UPS、空调、温湿度、防水、烟雾、视频、门禁、防雷、消防系统等)进行全天候不间断的监控与预防性维护。

4.贯穿服务流程

• 事件流程；
• 问题流程；
• 配置管理流程；
• 变更流程；
• 发布流程。

(1)事件流程

事件是指IT系统运行中，发生的任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的IT系统故障。事件处理流程涉及许多IT部门和IT方面的专家。首先是服务热线，服务热线(一线)作为事件的受理责任人，确保首问负责制的流程在整个IT运维服务流程中贯穿实施。当服务热线不能解决发生的事故时，就将其转移给二线技术支持小组。二线技术支持人员首先需要提供临时性的解决办法或补救措施，以尽可能快地恢复服务，避免影响用户正常业务的开展。然后二线技术支持人员分析事件发生的原因，制定解决方案以彻底恢复服务和业务的正常运行。

(2)问题流程

问题是指存在某个未知的潜在原因导致一起或多起事件发生。问题经常是分析多个呈现相同症状的事件后发现的某种状态。问题也可以从单个重要的事件中确认一项错误。这种错误产生的原因虽然未知，但其产生的影响却可能非常严重。问题流程负责解决IT运维运营过程中遇到的所有问题。问题流程包括问题管理和问题控制，其目标在于将由于IT基础架构的错误而导致的问题和事件对业务产生的负面影响减小到最低，以防止与这些错误有关的事件再次发生。为了实现这个目标，问题流程调查分析事件的根本原因后采取有关行动改进或纠正这种状态。

(3)配置管理流程

配置管理是指识别和确认IT系统的配置项，记录和报告配置项状态和变更请求，检验配置项的正确性和完整性等。配置管理流程就是有关如何管理和及时提供准确可靠的IT基础架构配置信息等活动构成的流程。配置管理不仅仅提供单个IT组件的信息，它还提供有关各个配置项之间关系的信息。这些信息是对IT系统故障影响程度分析的基础。配置管理流程负责记录有关IT基础架构的变更情况，监控IT组件状态，确保服务管理人员可以清楚地了解各个版本配置项的信息。

(4)变更流程

变更是指在维护过程中对IT系统或服务所做的各种改变，包括增补、移除和其他修改。
变更流程包括变更计划和变更控制，该流程旨在将有关变更对服务级别承诺中的运维服务绩效指标达成而产生的冲突和偏离减小到最低程度。变更流程的实施以变更请求、配置管理数据库和变更实施进度表为基础，经过登记变更请求、筛选和接受变更请求、确定优先级和归类变更请求、制定变更实施计划、实施变更、评价和终止变更、处理紧急变更和变更活动之后，产生变更管理报告等管理信息。

(5)发布流程

发布流程是对经过测试后导入实际应用的新增或修改配置项进行分发和宣传的管理流程。发布流程涉及到已经定义的IT服务的变更，这些变更通过对一些新应用软件与升级硬件或新硬件的结合使用来完成。发布流程和变更流程、配置管理流程是紧密结合的，当新发布引起IT基础架构的变更时，配置管理数据可进行实时的更新，同时发布的内容也要保存到最终软件库中。

我的实践:
上述理论知识，阐述完毕。聊聊我的实践，在某创业公司的时候，我就已经实践的一小部分，然后再到教育SaaS公司，教育SaaS公司的运维体系是最为完善的，把上面的理论知识同实际相结合，虽然在教育SaaS公司我不是做运维的，但在涉及到客户反馈的问题处理过程中，我与运维紧密配置，运维提供详细的错误日志信息和客户反馈的情况，而我则依据对应的错误日志信息和客户反馈的情况进行相关的问题定位、问题分析以及最终的问题解决。而在M2公司的时候，前期公司没有运维，由我兼任运维，规划出了三套环境分别对应开发、测试、预生产环境等，实际中也出了很多问题，比如预生产环境需要给客户演示看，面对预生产环境，我本人奉行的就是快速解决问题，以保障客户的体验。上面的理论相关的知识，在我所处的四家公司中，或多或少都体现了。