7.9k 字 82 分钟

前文回顾

前文假设我们接手了一个党政机关的乙方运维项目，主要讲述前期资料收集的工作。

前文链接: 给你一个乙方运维项目，你会如何开展工作呢？（上）

在收集了一系列资料以后，就可以正式开始我们的表演了。接下来将会以技术、管理的双重视角，讲述乙方运维应该如何推进。

现在，你手上至少会拥有以下几种的文档

  • 业务系统信息表
  • 业务系统拓扑图
  • 网络资产信息表 网络设备、安全设备、审计设备
  • 网络拓扑图
  • 硬件设备资产信息表 服务器、光纤交换机、存储设备
  • 计算资源资产信息表 IAAS、PAAS、SAAS、容器、各类云资源
  • 通信录 包括甲方、乙方、第三方厂家等相关人员的联系方式

OK! let’s go!

知识库

根据以往的经历，大多数党政机关单位都会设有档案管理员，他们大多负责的都是公文类的纸质文件或者电子档案。
随着 IT 系统的建设，也会相应产生各种文档，例如系统使用手册、管理员手册等等。
这些不太敏感的文档可能会交由信息化办公室来处理，然而依然会存在各种问题，例如：

  • 由于文档的变更，同一份文件存在多个版本，落到每个人手里的版本不一致；
  • 新入职的员工各种找不到文档；
  • 电脑坏了，文档全部丢失；
  • 文档管理混乱，关键时候找不到文件；
  • 相关人员休假了，找不到文档干着急；

所以建立一个健全的知识管理库Wiki十分重要，也是我们首要完成的任务。

注：涉及敏感信息的文档，应当按照机构的规章制度交给档案管理员处理，这些的敏感资料不在这次讨论范围。

Wiki 软件

个人建议尽量使用云厂商提供的知识管理库服务，不但功能完善，也不需要增加运维成本。
如果机构对信息保密有比较严格的要求，也可以在内部网络搭建 Wiki 系统。

公网 Wiki 可以考虑：

  • 语雀
  • 腾讯 TAPD

内部自建 Wiki 可以考虑:

  • Atlassian Confluence
  • dokuwiki
  • mediawiki

在线文档

日常办公有各种类型的文档，例如：PPT幻灯片、PDF文档、Visio图表，这些使用 Wiki 无法很好的展示，这时候就可以使用在线文档
在线文档基本都有：版本修改记录追溯、多人协作、读写权限管理、在线分享等功能，足以满足办公需要。

这里推荐：

  • 腾讯文档
  • 石墨文档
  • 金山在线文档
  • Google 文档

笔者就是使用腾讯 TAPD + 腾讯文档的组合来完成文档管理的。
以 Wiki 充当公共索引，在 Wiki 正文附上腾讯文档的链接，如果遇到在线文档无法很好展示的情况，就以附件形式附在 Wiki 页。

资料分类管理

把前期收集的资料都整理好，按照分类放在 Wiki 上，能放上去的尽量放上去。
分类的参考：

  • 系统架构
    • 系统信息表
    • 系统架构图
    • 容灾方案
  • 资产信息
    • 硬件资产台账
    • 软件资产台账
    • 产品技术白皮书
  • 网络架构
    • 机房建设情况
    • 网络规划使用情况
    • 网络拓扑图
  • 组织架构及通信录
    • 组织架构图
    • 各类通信录
  • 日常工作类
    • 各类流程
    • 各类规范
  • 会议记录
  • 事件及故障
  • 经验知识

资产库

如何建设资产库

所谓资产库简单来说就是记录资产台账的地方，它有如下几个特点：

  • 随着 IT 系统运作，变动频繁
  • 记录条数很多
  • 数据准确率要求很高
  • 有团队内部信息共享的需要

因此不建议用 Excel 之类的电子表来记录，在部门信息共享的时候，很容易造成记录冲突、错位等。

在项目的前期，建议使用在线文档-表格来进行管理，给资产管理人员开通读写权限，其他相关人员开通只读权限即可。
在后续的持续建设当中，可以引入 CMDB 系统作为管理（后面有相关的讲述）

注: 在完成前期的数据收集以后，建议多去核查几遍，以防无效数据录入到资产库

资产的种类

资产的种类，包括但不限于以下的部分：

  • 物理资产：
    • 机房设施
    • 安全设备 防火墙、防毒墙、IPS、IDS
    • 网络设备 负载均衡器、各类交换机、网闸
    • 服务器设备 服务器、存储、光纤交换机
  • 软件资产：
    • 各类业务系统
  • 虚拟资产：
    • IAAS 虚拟机、弹性IP、对象存储、负载均衡
    • PAAS 各类缓存、数据库、队列服务、计算框架
    • SAAS CDN、云WAF、图片识别、网盘等
    • K8S 容器
  • 无形资产：
    • 各类平台的账号密码
    • DNS 域名记录
    • SSL 证书、CA 证书
    • 各类系统文档

标准与规范

为什么要标准化？

简单举几个例子：

  1. 关于办公文档资料，A 员工喜欢收集整理到 Wiki，B 员工则喜欢放在工作 U 盘上面。久而久之，文档就产生差异了，那到底以谁为准呢？
  2. 周报日报，A 员工喜欢以邮件形式发送给，B 员工喜欢发到微信群。这必然会给统计人员增加工作量，出错的机会也会增加。
  3. 软件部署，A 运维把软件安装在/www，B 运维把软件装在/data，C 运维喜欢装在/opt 目录。造成重复安装怎么办？

可见，无论是在技术层面还是管理层面，只要存在差异就必然是安全隐患，轻则工作汇报被客户臭骂，重则影响业务系统的运作，也会提高以后的自动化建设落地的难度。

为什么要规范化？

规范化可以理解是标准化的基础上进一步的完善。标准化的主要目标是减少差异，规范化的目标则是提高效率。
举个例子：

  1. 不同运维人员写脚本所使用的编程语言、编码、注释等方面都存在巨大差异，日后问题追溯必定会浪费大量时间；
  2. 系统版本、主机名、IP 段划分意义不清晰、不规范、不能一眼辨识资产作用，这间接或者直接增加监控难度，增加故障排查的时间；
  3. 给甲方写汇报材料的格式混乱、用词不一、落款含糊、邮件标题随意等，必然会降低甲方对乙方的评价；

流程优化

例如在某次汇报当中，甲方代表、运维经理、第三方厂家正准备开会，突然一个业务部门电话打过来，要求马上做一个日常的数据库操作，结果这个早就预定的会议被生生耽误了半个小时，运维经理亲自去处理了。

运维经理的主要工作，是对运维工作整体的规划、组织、决策、控制。数据库的操作仅仅是运维日常的一种。
如果将这类的工作预先进行规划，明确人员职责，制定专门的流程，一旦同类事件发生就按照流程去处理，就能解放管理者的事件，运维经理也就不必亲自挂帅去处理。

流程优化的要点

  1. 除去繁杂，缩短流程：
    时间就是金钱，时间就是生命! 我们制定流程的目的是提高效率，无效或多余的环节都不应该出现。

  2. 关注流程的合理性：
    假设在事件管理流程中，如果发现 Case 经常停留在某个角色，而且角色仅仅是被通知而已，那这个流程就应该做优化，这个通知的动作应该改为平行处理，不应该让他卡住这个流程。

  3. 明确职责与工作量：
    在流程中每个角色的都应该有明确的职责分工，管理人员只做审批，技术人员只管技术，尽量避免一人担任多个角色；
    而且要关注角色的工作量，一旦发现瓶颈就要尽快消灭掉，多增加同类型的角色，或者把他的工作量拆分；

  4. 关注成本：
    运维的任何调整都是有成本的，在调整之前要充分考虑成本变化，包括在组织结构、人员能力、工具辅助等各个方面的成本；

事件管理

概念

事件管理是运维管理很重要的组成部分，目的是为了保障 IT 系统的运行健康，遇故障能尽快恢复，保障业务稳定可控的情况下不断的完善现有系统。
需要考虑 3 个指标：时间、质量、数据记录
也就是说，在及时处理事件、需求的前提下，关注处理质量以及做好数据的记录，同时要完成事件跟踪、统计、分析，变被动运维为主动运维，避免业务方“追债”。

相关的概念：

类型：

名字定义例子
事件意外的故障、问题，例如服务中断、运行异常、服务质量下降等系统登录异常；网络中断；无法登录等
需求计划之内的变更，影响均在可控范围之内新业务上线；程序迭代；设备维护等

角色：

名字定义例子
服务台IT 事项的统一连接点，负责事件的受理、记录、追踪、解决、回顾等10086 热线；员工服务台
二线人员协助一线人员处理事件，提供技术调研、技术支持，保障事件快速解决技术专家；开发团队；三方厂家
一线人员事件的实际处理人，负责接收服务台指派的任务，提供解决方案或者快速处理运维工程师、DBA、网络技术

事件管理流程设计重点

  1. 清晰流程框架，事件管理的流程主要可以分为 3 个阶段：事件识别、调查和解决、事件关闭。

具体流程可以参照下图：

  1. 明确责任分工，例如：统一由服务台与客户进行沟通、记录与分派任务，从而也避免了本文开头提到的运维经理重要管理工作被客户打断的情形。一线人员就只负责事件的处理，除非必要，尽量别让其他人打扰一线人员处理事件。

  2. 时间管理，服务台需要对事件进行分级，再根据优先级排序，合理安排处理时间。并且需要跟踪，定期询问一线人员进度情况，可以参考事件分级的模型：

事件分级定义响应时间解决时间
P0核心业务重要功能不可用且大面积影响用户立即响应<2 小时
P1核心业务重要功能不可用，但影响用户有限，如仅影响内部用户<15 分钟<2 小时
P2核心业务周边功能不可用，持续故障将大面积影响用户体验<1 小时<3 小时
P3周边业务功能不可用，轻微影响用户体验<3 小时<1 个工作日
P4周边业务功能不可用，但基本不影响用户正常使用<4 小时<2 个工作日

事件工单

对于每日业务量、咨询量相对偏小的部门，如果没有专业工具支撑事件管理，也可以利用 EXCEL 来完成的工单记录表，先让流程跑起来，积累一定数据与管理经验，再考虑采用哪种管理工具。

事件数据分析

运维需要用数据说话，通过量化数据的统计分析，能让大家看到我们管理的成效，也能发现不足之处、风险隐患等等。帮助管理者更好的开展后续的计划、组织与控制。从而不断完善优化运维工作。

可以从事件总体处理情况、某周期内事件发生情况等多角度进行统计分析，好的统计报告能让不同的角色“各取所需”，快速得到他们想看到的信息。参考如下样例：

团队协作

晨会

团队协作是运维管理里面很重要的一个环节，也是 Team Leader 必不可少的课题。这里可以参考 Scrum 敏捷实践的Daily stand up meeting，即每日的早晨站会机制，通常在每个早晨进行，时间大约持续 15 分钟。

在以前互联网公司的实践当中，我们每天早上 9 点，会在相同的地点准时召开站会。站会的主要目的就是为了让组内成员快速了解每个人昨天做了什么，今天打算做什么，有没有困难阻碍，需不需要协助，要不要调整工作计划，最终的目的是为了更有效的沟通，提高团队的工作效率。下面总结一下站会的一些要点。

  • 与会成员：全组成员
  • 会议时间：每天早上 9:00－9:15
  • 会议地点：任何不被打扰的地方。
  • 会议内容：
    1. 昨天做了什么。
    2. 今天的计划。
    3. 遇到的困难或者阻碍。

关于站会的注意事项：

  1. 应在固定时间固定地点召开站会，不应迟到，早退, 缺席。这样做的好处在于能够让大家形成习惯，沟通也会变的更自然顺畅。

  2. 所谓站会，顾名思义就是站着开会，不应该坐着，甚至躺着。站着开会可以使会议开的更快速高效，保证在 15 分钟内完成。如果以一种很舒服的姿势开会的话，那么这个会恐怕会脱的很长，也就违背了站会的初衷。

  3. 每个人应简洁适当的陈述自己的工作状态，不要深入细节。尽量不要超过2分钟.细节的讨论可以放到线下讨论。会议中我们只关注状态，遇到的问题。

  4. 有一个误区就是成员总是认为向 Leader 汇报自己的工作，其实不然。站会中每个人轮流发言，是为了向团队每个成员汇报自己的状态，以便让每个人了解你的工作内容、进度、需不需要协助，以及能不能从你那里寻求到帮助。是为了更好的沟通交流，以便达到更高的效率。

  5. 一次一人轮流发言，其他必须注意倾听，也可以提问，但不能交头接耳，或者做其他无关的事情。注意倾听，首先是一种尊重，其次你可以更清晰了解别人的工作状态，进而能够更顺畅的协作，甚至获取帮助。

看板工作法

看板管理，就来自日语“看板”，是丰田生产模式中的重要概念，指为了达到准时生产方式（JIT）控制现场生产流程的工具。

相比于工作会议，看板方法更能直观的体现整个团队的工作状态。

在以前，很多团队在工作的时候都会多多少少接触到一些物理看板，但是随着时代的发展，物理看板的弊端就会逐渐显现出来，比如说当团队里有人出差需要远程办公，又或者工作繁杂工作量巨大，这样，物理看板就无法满足需求了。

摆脱物理看板而使用软件来开展看板工作法是必需的。

工作看板的内容主要分为以下几个部分：

  1. 泳道（甬道）：每个泳道都是过程中的一个阶段。例如运维最常见过程：需求提交 –> 已确认待处理 –> 进行中 –> 已完成
  2. 卡片：团队需要处理的任何事。运维团队关注的是各类故障、需求、变更等等，注意按优先级排序再开展工作
  3. 人员：在已确认的卡片上，必须与人员挂钩。这样既可以看到每个组员的任务数量，避免某位成员的工作量太大，也可以避免 “事件无人跟进” 的尴尬情况。

看板软件推荐：

这两个软件都是既有网页版，也有手机版，功能也都比较齐全。

工作汇报

乙方运维工作中，给甲方的工作汇报是必不可少的一个环节，也是体现乙方工作量的一个很重要指标。
会议形式可以以周例会、月例会、季度例会的形式组织汇报，如果涉及多个厂家可以让他们一同参加汇报。

汇报材料：

  • 日报：因为日报每天都要发，并不建议说太多啰嗦的内容。以事情汇报为主，简明扼要的叙述就好。
    例如昨日事情完成情况、今日事情完成情况、需要协调的资源有哪些等等。
    当然，有突发事件、重大事件，也可以另外的篇幅去写

  • 周报、月报：事件汇总，挑重要的事项汇报完成情况，下周/月的计划事项等。建议附上数据报表作为支撑，例如事件处理的 SLA 情况、告警报表、业务系统的性能报表等，以统计数据来说话。

  • 季报、年报：与周报类似的要求，可以补充更多的数据，也可以附上一些事件报告之类的。
    笔者不太喜欢这类型的报告，实时性太差了。这些这个属于项目验收上面锦上添花的东西，在项目实践当中周报、月报就足够了，甲方也比较愿意看这些

  • 事件/故障报告：应至少包含故障现象、开始时间、结束时间、处理记录、故障原因、后续改进。
    做成表格会让人感觉更正规专业一些，可以留个领导签字的地方，给领导装装 X。

监控告警

无监控，不运维！，这句话一点都不夸张，监控俗称第三只眼。木有监控，什么基础运维、网络运维、业务运维都是瞎子，可以说是运维职业的根本。尤其现在敏捷开发、DevOps 这么火，频繁的更新迭代很容易出 BUG。这个锅很大几率直接甩到运维的头上，背锅侠就是由此而来。
监控做得好，有了充足的数据作为支撑，无论事前及时预警，还是故障及时发现，都可以应付得游刃有余，自然也少背锅。

监控的指标

言归正传，完整的监控流程应该包含以下几个步奏：

  • 数据收集：相关的数据要统一、集中的收集
  • 归类存储：
    • 热数据：最近 15 天的数据，需要经常的检索，建议放在性能好的集群、或 SSD 磁盘；
    • 温数据：15 天至 60 天的数据，检索较少，可能会用来绘制报表，可以放在性能较弱的存储；
    • 冷数据：60 天以前的数据，基本不查，但需要归档存储，可以放在磁带、性能差容量大的磁盘、或者直接归档到云存储；
  • 检索与分析：需建立有效的检索机制，有需要可以随时调阅，敏感数据特殊处理等；
  • 数据展示：需要满足类数据报表、做更宏观的统计分析等；
  • 告警：设置报警阈值、报警策略，当业务异常的时候迅速的通知到责任人；

监控指标包括以下几点：

  • 硬件：设备温度、风扇、电源、磁盘、设备负载；
  • 系统：CPU、内存、磁盘容量、网络 IO、磁盘 IO；
  • 软件：进程、线程、端口、GC 情况、OOM 情况；
  • 业务系统：QPS、TPS、日活、高峰低峰时间段等；
  • 网络：流入、流出、各类核心链路情况、DNS 解析情况；
  • 日志：各类业务日志、异常报错日志等；
  • 性能：DNS 响应时间、接口响应时间、后端响应时间、异常响应码的数量、慢 SQL 数量、Redis SlowLog 等；
  • 证书有效期：例如 K8S 的证书、各类 SSL 证书 千万要注意！笔者多次采坑！

监控工具

  1. Cacti
    很老的一款监控工具了，其实说它是一款流量监控工具更合适，对流量监控比较精准，但缺点很多，出图不好看，不支持分布式，也没有告警功能，所以使用的人会越来越少。

  2. Nagios
    俗称难搞死，也是老牌网络监控工具，特别是告警功能很强大，支持的告警方式也很多。但缺点是缺乏数据收集机制，出图也很简陋，监控的主机越来越多时，添加主机非常麻烦。
    配置文件都是基于文本配置的，不支持 web 方式管理和配置，这样很容易出错，不宜维护。

  3. Zabbix
    zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix 解决了 cacti 没有告警的不足，也解决了 nagios 不能通过 web 配置的缺点，同时还支持分布式部署，这使得它迅速流行起来，zabbix 也成为目前中小企业监控最流行的运维监控平台。

  4. Prometheus
    Prometheus 新一代的开源的系统监控报警框架，它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus 的多维度数据收集和数据筛选查询语言也是非常的强大。Prometheus 是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。

  5. Grafana
    Grafana 是一个开源的度量分析与可视化套件，通俗的说，Grafana 就是一个图形可视化展示平台，它通 过各种炫酷的界面效果展示我们的监控数据。
    如果你觉得 zabbix 的出图界面不够好看，逼格不够高，就可以使用 Grafana 的可视化展示，同时， Grafana 支持许多不同的数据源，Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch， CloudWatch 和 KairosDB 都可以完美支持。

  6. 全链路跟踪监控 APM（例如 Pinpoint、听云、skywalking、腾讯 TFS）
    更偏向于业务级别的监控，实现分布式链路追踪、应用级别性能监控（jvm 等），提供应用性能追踪能力，用户通过应用全景拓扑，实时了解应用的运行状态，快速故障诊断。通常配置有程序探针，随着程序模块启动而启动

  7. 第三方监控（监控宝、360 监控、百度统计、阿里云监控等）
    厂家一堆文档，我就不叙述了。反正就是厂家帮你搞定一堆繁琐的事情，既有钱又想省事，选他就对了。

这里比较推荐：

  • 中小企业监控平台选择 Zabbix，一个软件搞定；
  • 有一定运维能力的互联网、大企业、推荐 Prometheus + Grafana 的监控体系，监控力度精细、报表好看、性能优异、跟 K8S 一类的新架构贴合度很好；

告警路径

按主流有：

  • 钉钉
  • 企业微信
  • 微信公众号
  • 短信
  • 语音电话
  • 邮件

通常是组合使用，优先级高的用语音电话、短信，优先级低点的就其他网路告警。

监控告警是一个精细活，有机会再另开主题，与大家分享

自动化

刚接手运维工作，你可能会遇到以下的问题：

  • 大量繁琐的手工操作
  • 无法消灭的变更出错
  • 人员变动的培训门槛
  • 被各种应急搞得鸡飞狗跳

在某些较为传统的企业、党政机构情况可能会更加严重，大量的人肉运维工作会让你怀疑人生。
作为运维经理，应当以技术的思维与角度去解决问题，办法也很简单：工具化 + 自动化

目标：

  • 让程序来完成那些重复性高、繁琐的工作
  • 减少人为的犯错几率，降低手滑造成的风险
  • 形成规范，一致性的操作，提高可控性
  • 运维以外的人也可以操作
  • 所有操作都可记录、可追溯

如何实现？

  1. 挑选合适的工具来处理具体问题，例如：
  • PXE，实现服务器上架之后，自动安装操作系统；
  • Jenkins、GitLabCI 解决代码标准化打包、部署的问题；
  • Ansible、SaltStack、Puppet，批量部署，批量执行，解决环境一致性问题；
  • JumpServer 管理资产，作为生产的跳板机+堡垒机，解决安全性问题；
  • Jira、Confluence 等工具完成团队协作、问题管理；
  • ELK 处理日志统一收集；
    ….
  1. 工具解决不了的问题，自己动手编程来处理，例如：
  • 编写脚本解决日常重复性的工作，如数据库备份、自动归档工单、自动发邮件等；
  • 编写一个 API 来连接多个工具，实现复杂的功能；
  • 用 Django、Flask、vue-elment-admin 等框架，制作运维管理平台；
    …

安全

随着 IT 技术蓬勃发展，各类黑客事件屡见不鲜。相对于常规的网络攻击之外，我们还需要提防有着更大破坏性的系统入侵、敏感数据泄露等问题。特别是党政机构的公开系统，出现问题可能还产生政治责任。
安全是一个很大的命题，能够做好也实属不易，可以从以下几方面入手：

  1. 访问控制
    可以基于以下的层面进行网络隔离控制：

    • 网络层：使用物理防火墙、IPS 设备等隔离各环境的网络边界，严格控制外部网络访问；
    • 操作系统：开启系统防火墙，关闭不必要端口，禁止 Administrator/root 等超管的网络登录；
    • 应用层：内部划分 DMZ 隔离区，将数据库、缓存库等置于 DNZ 区域，制定 IP+端口级别的点对点准入准出规则；

  2. 统一入口管理

    • 部署跳板机、堡垒机，生产网络只允许这类设备访问，实现运维入口的统一化。集中访问控制之外，还 需要有命令限制、操作录像等审计手段。可以购买商用的软硬件产品，或使用JumpServer之类的开源软件；
    • 办公局域网与互联网配置隔离策略，内部系统不允许直接外网访问。远程办公人员需要通过 VPN 才能使用内部资源；

  3. 安全基线配置
    可以根据等级保护、分级保护的标准，在操作系统、网络设备、数据库等进行安全基线配置，例如：用户登录超时、密码复杂度策略、删除多余用户、禁止 Telnet、禁止不安全的 SNMP、禁用 sa、开启数据库审计策略等；

  4. 信息系统扫描加固
    使用 AWVS、IBM APPScan、Nessus 等开源或商用的扫描软件，定期对生产业务程序、操作系统、网络设备等进行扫描，根据扫描结果进行加固；

  5. 漏洞补丁、安全软件
    在服务器、个人电脑都安装安全软件，通过 AD 域控制、安全管理软件等强制定期更新补丁，有条件还可以搭建 WSUS、企业杀软等进行补丁统一管理；

  6. 第三方安全服务

    • 邀请第三方定期对生产的业务系统进行扫描、入侵检测；
    • 购买第三方安全服务，如知道创宇的创宇盾，网易易盾等；

  7. 数据安全

    • 严格的访问控制，数据库只允许掌握在 DBA 手上，开发、测试无权直接访问生产库；业内赫赫有名的微盟删库事件、思科删库跑路事件
    • 严格的网络控制，参考 DMZ 策略，开放 IP 点对点的网络访问控制；
    • 敏感数据脱敏处理才能打印到日志，数据分析决策系统严控用户数据批量导出，防止数据泄露；
    • 各类型的备份，设置数据库镜像、数据备份多点保存（如异地机房备份）、应用配置中心、系统日志业务日志的备份、加密归档至公有云；
    • 数据库的操作必须多重审核，也可以使用 SQL 审核平台 Yearning

  8. 代码安全

    • 搭建内部 Svn、Gitlab 等代码仓库，把业务代码集中管理，严格控制访问权限，防止代码泄露；
    • 使用 sonar、shipshape、error-prone 等工具定期扫描，避免各类安全漏洞；

小结

有一个误区需要注意，就是传统的两级分化思维：运维经理只懂管理就够了，技术交给别人去做。
如果只会管理不懂技术，做事往往纸上谈兵，很容易就会被人忽悠。好比甲方给你一个数据备份的需求，原本写个脚本就可以解决的事情，非得去找厂家写方案。人家当然乐意了，一坨高端大气上档次的方案甩你脸上，高新设备全部一起上。最终花了几十上百万，效果还一般。甲方一顿臭骂还算好，下年的合同可能就飞走了。（当然，厂家跟你是一路的就另说，一起忽悠甲方也挺好的）

相反，一个盲目技术信徒，遇到新技术都爱往生产上面怼，必将造成生产架构的混乱，到处是技术烂摊子，出现故障没人敢碰。只懂技术、不懂方法论、没有项目思维，有可能一件很简单的事情都做不好。

所以传统的两极分化思维，最终会被淘汰的。

优秀运维管理，是以方法论为指导，技术能力作为支撑，最后沟通协调能力锦上添花，一系列优雅结合而成的产物。作为新一代的运维经理，必须不断的了解新生技术，学习业内优秀的方法论，同时以严谨的态度对待每件小事。保持乐观开放的心态，紧跟时代的节奏，这才是生存之道。

参考文章

https://mp.weixin.qq.com/s/W5PF4Si3SnmnBW57hWxq2w

http://linuxops.xyz/2020/03/06/%E5%A6%82%E6%9E%9C%E7%8E%B0%E5%9C%A8%E7%BB%99%E4%BD%A0-500-%E5%8F%B0%E6%9C%8D%E5%8A%A1%E5%99%A8%EF%BC%8C%E4%BD%A0%E4%BC%9A%E5%A6%82%E4%BD%95%E7%AE%A1%E7%90%86%EF%BC%9F/

https://yq.aliyun.com/articles/746302

https://zhuanlan.zhihu.com/p/21896523

https://sspai.com/post/52797

https://zhuanlan.zhihu.com/p/63827651

 目录