「运维困境与破解之道」

index

物理是由谁来做那些事，类似基础设施架构规划、容量规划、系统运行维护、监控、安装补丁、安全监查、内部工具的开发以及平台管理这些任务仍将存在。运维工程仍将是一个专门的工程态。

职责

由于每家公司本质上都是一家软件公司，运维团队支持的应用程序不再仅是次要的、内部使用的。在许多组织中，这些应用程序时收入的驱动因素，是公司盈利能力的核心。随着从内部工具到创收的转变，运维团队需要对所支持的应用程序有更深入的理解，且压力会越来越大。同时，应用程序开发人员需要更详细的了解他们的系统在生产中是如何运行的。随着系统的增长和越来越复杂，在准生产系统中进行全面测试的想法越来越不可行。为了应对挑战，运维与开发都必须了解这个系统是做什么的，然后，他们必须能够确认它确实在做它应该做的事情。没有错误并不意味着事情按预期进行。

DevOps

DevOps目标：

增进团队之间的合作；
减少多余的关卡和交接
用工具以及授权赋能开发团队拥有他们的系统
创建可重复、可预测的流程
共享对应用程序生产环境的责任

DevOps支柱：

文化：建立团队之间新的沟通方式或者团队结构
自动化：把人力投入从琐事中解放出来
度量：判断某件事是否有效的方法
分享：知识管理的重要性令人难以置信

了解产品

运维团队应对异常情况的能力取决于对正常情况的了解。这些知识只能来自对产品的了解和长期观察，就像亚马逊的许多产品一样，不了解产品的运维工程师很快会被“基础设施即服务”解决方案所取代。对工具的专业知识以及对公司产品和业务的了解才能是运维工程师变得有价值和必要。了解产品时DevOps组织的必要条件。如果你不能从业务视角理解并增加价值，那可能就沦为一个离失业不远的简单应用API。

运维可视化

运维可视化根植于两个主要来源：度量和日志。度量是系统资源在某一时间点的指标。日志是系统生成的消息，描述系统中发生的事件。系统正常运行的三个特征：

吞吐量：任何给定时间流经系统的请求数
错误率：对错误计数的计算，表示为请求总数的百分比
延迟：对特定操作发生所需时间的度量。

发挥日志作用

实现日志聚合
确定日志级别

自动化

当涉及工具和自动化时，你必须考虑的不只是正在构建的产品或者功能。你需要围绕产品的整个系统。人员、支持系统、数据库服务器和网络都是解决方案的一部分，如何管理和处理这些系统同样重要。

自动化的重要性

自动化带来的改进

排队时间
执行时间
执行频率
执行差异

没有自动化的原因

没有足够时间
永远不会被优先处理
紧急胜过正确

自动化和工具化的人员配置

单一技能体系的团队
环境的牺牲品

解决文化层面的自动化问题

不允许手动任务
支持“不”作为答案
手动和自动化之间的调和

定义自动化目标

将自动化作为所有工具的要求
在工作中优先考虑自动化
把自动化作为员工的优先事项
为培训和学习提供时间

达到自动化

事故

最佳的学习实践不是从正确中学习，而是从错误中学习。事故时验证你对系统的理解是否符合实际情况的一种有效方式。为什么系统会发生问题以及如何能对其改进，就是事故带来的精华。

事后剖析时团队分析事故原因的过程，通常采用的方法时召开所有利益相关方和事故处理参与人员参加的会议。

好的事后剖析的组成部分

创建心智模型

想搞清楚事故是如何发生的，关键是要先了解人们对系统和流程的看法。当你使用系统或者称为系统的一部分时，你会对他产生一个心智模型。这个模型反映了你对系统表现和操作方式的理解。

遵循24小时规则

发生事故24小时之内应该开展事后剖析。

确保细节完整
确保充分利用失败背后的情绪和能量
确保创建事后剖析文档

制定事后剖析规则

永远不要直接批评一个人
假设每个人基于当时能够获取的信息已经做到了最好
需要知道，现在事实看起来似乎很清楚，但在当时可能是模糊的
指责系统，而不是人员
最终目标时弄清导致事故的所有因素

开展事后剖析

选择参与人员

项目经理
业务利益相关者
人力资源(HRBP)

整理时间线

详细叙述时间轴上的每个事件
1. 执行了什么动作或事件
2. 由谁执行的
3. 什么时间执行的
添加事件上下文
1. 为什么感觉这是正确的行动
2. 是什么让你对系统中发生的事情做出了这样的解释
3. 你有没有考虑过其他行动，如果有，为什么要排除这些
4. 如果让其他人来做这个行动，他们如何知道你当时所知道的这些情况呢？
定义和跟进行动事项
1. 行动事项负责人
2. 跟进行动事项