物联网解决方案在于可靠的网络连接

同时，面向一线的运维人员，我们需要根据同一个系统或设备的多个监控指标进行综合性建模和分析，汇总成一个健康度的分值，给予一线运维人员系统的基于健康度的系统分层评价体系，真实、直观反映系统运行状态，实现问题快速定界。

比如，通过基础资源的多个指标进行综合加权计算来整体评估该资源的利用率;通过一个应用关联的全部资源的资源利用率以及应用的运维架构整体建模分析来计算一个分值来整体评估该应用的健康程度。

这个过程如果做得成熟一些，可以根据内部已有的解决方案和告警进行闭环打通，一个简单的场景就是，当磁盘满时，告警会首先触发一次标准化的磁盘巡检，并进行相关的可丢弃数据的删除，如果依然无法解决该报警，下次可直接关联到一线运维进行人工干预，之后进行标准化经验总结。

故障复盘

故障复盘就是对于过去的一些服务异常和服务中断情况进行回顾和总结，以确保相同问题下次不会再出现。为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统。

备注: 其实在国内的SRE文化中，一般只有对大型，对业务有重大影响的事故才会进行复盘，但实际上如果在时间和经历允许的情况下，对于一般的普通事故也应该在小范围进行复盘，正所谓大的故障都是从不断的小问题一点一点积累的。另外，其实对于运维相关的个人而言，我们也应当及时的进行小故障复盘，以不断加强个人的故障处理和修复能力。

我认为SRE的一个关键共识正是承认了系统的不完美性，追求永不停机的系统是不现实的。基于不完美系统，我们无可避免要面对和经历系统故障与失败。

所以我们重要的并非找到为这个故障责任的这个人或者那个人，而是更应该创根问底地复盘这个故障和失败的根本原因是什么，以及如何避免再次出现相同的故障。系统可靠性是整个团队共同奋斗的方向，从失败中快速恢复并吸取教训，每个人放心地提出问题，应对停机，并努力改进系统。

备注：通常很多企业内部在故障复盘过程中，相关人员可能将故障和失败的根因追溯 不经意间 当做了故障定责和一系列的惩罚措施，通过一些惩戒措施来强行约定故障的发生，这种方式往往是非常不可取的，试想每个人都不想出现事故，要么是认知之外，要么是规则缺陷，永远没有一个人明知会有故障而偏偏去制造故障的。

需要牢记的是：故障是我们可以从中学习的东西，而不是让人害怕和羞耻的事情!

在日常运维过程中，出现故障等事故对于我们而言其实是一个很好的复盘学习机会。通过历史监控数据，分析事故其中的根本原因，制定后续应对策略，并且通过运维平台将这些应对策略编辑成标准化、可重用、自动化的运维应用场景，为后续相同问题的处理提供标准且快捷的解决方案。这正是事后回顾这个过程最真实的价值体现。

测试与发布

测试与发布对于整个稳定性和可靠性的主要出于一个预防的作用，预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。

作为一个长期从事运维工作的人，可能内心中最为恐惧的莫过于新应用版本发布。因为除了硬件和网络设备损坏这个属于天灾级别的概率事件外，新应用版本发布的第二天通常是停机与事故的高危期。所以，对于一些量级较大的产品通常会在节假日以及重要活动前夕进行封网操作，以避免新版本上线而导致的业务bug出现。

而测试是在成本和风险之间找到适当的平衡活动。如果过于冒险，你们可能就会疲于应付系统失败;反过来说，如果你太保守，你就不能足够快地发布新东西，让企业在市场上生存下来。

在错误预算比较多(即在一段时间内故障导致系统停机时长较少)的情况下，可以适当减少测试资源并放宽系统上线的测试和条件，让业务可以有更多的功能上线，以保持业务的敏态;在错误预算比较少(即在一段时间内故障导致系统停机时长较多)的情况下，则要增加测试资源并收紧系统上线的测试，让系统的潜在风险得到更多有效的释放，避免系统停机保持系统的稳态。这种敏态与稳态之间的平衡，需要整个运维与开发团队来共同承担。

除了测试外，应用发布也是一项运维团队通常要承担的责任。SRE的一个原则是将一切可以重复性劳动代码化和工具化;此外，应用发布的复杂程度往往与系统的复杂程度成正比。因此在应用系统上规模企业，往往已经着手基于自动化框架构建自动化的应用发布过程。

（编辑：鹰潭站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!