本文内容来自\_Seeking SRE\_一书。虽然讲的是互联网企业的SRE，但是对于物联网也有一定的借鉴作用。
作者：与子同袍
首发：物联网前沿技术观察
物联网平台软件开发商可以从中吸取如下经验：
- 企业搞物联网，最终不能只建了个监控中心花架子。很多物联网方案落地时，都喜欢搞一套大屏，给领导和客户参观时秀一下。其实这个是本末倒置。
- 物联网属于远程分布式系统，出现问题不一定好调试解决。因此需要在这方面加强技术手段，在出现故障时能够获取现场日志信息，便于复现问题找到原因。
- 物联网软件平台的可靠性很重要。很多做物联网软件的企业是工控软件出身，对互联网软件运维这一块其实不是太了解。它们需要借鉴互联网企业的SRE的最佳实践，提高物联网服务的可靠性。
- 当物联网设备数量多了后，需要有配置管理工具，进行批量管理，并记录相应的变更。这一点我觉得当前很多物联网软件平台很欠缺，也是很多客户觉得物联网软件平台界面功能不好用的主要原因。物联网软件平台的开发商需要重视这一点。
- 物联网监控中心放人盯着屏幕是不对的。
- 物联网系统不能乱发告警。
- 产品出现问题，不能只靠运维人员，开发人员也要参与。
第一条，不要依赖监控中心
做物联网的，都喜欢搞个监控中心。监控中心里放N块大屏。上面有地图、实时汇总数据、告警之类的。领导来参观的时候倍有面子。
但是实际上监控中心没啥用。里面一堆人聚在一起，吵闹嘈杂，运维效率很低。
正确的做法应该是不同人员分布在不同地方。当出现问题时，运维系统给相关人员发送必要信息进行处理。
实时数据交互通过聊天软件分享给相关人员。
大家盯着一个屏幕并不对，而是应该每个人都处理相关的信息，然后通过工具分享协作。就像火箭发射中心那样。
第二条：运维工程师不要老是盯着屏幕
不能指望靠人去对着屏幕分析数据，然后发现故障。
应该尽可能用机器去对大量数据进行分析，发现其中有问题的地方。
不要用人去盯着数据，而是构造一个系统代替人去盯着数据并发现问题。
运维工程师应该开发工具，让工具去代替人盯着。运维工程师只有在需要人工干预时才需要通知到。要是系统能够自动进行修复，那就更好了，因为机器比人反应快。
第三条：不能乱发告警
告警不能乱发给所有运维人员。因为所有人都会一下子紧张起来，影响不相干的人的效率。
因此告警时，只通知必要的相关人员，让这些人全力解决问题。但是保护其他人的注意力和精力。
第四条：根问题不等于人犯错
许多公司的老板在出问题后，喜欢要相关人员做根源分析。
分析的结果肯定是某种人为或者系统软硬件的原因。
他们脑子里有一种幻觉，认为做了根源分析，就可以下次不再出现问题了。
但是实际上这样做，对提高系统可靠性并没有太大作用。
我们不能把问题归结到人或软硬件的错误。而是应该认为系统有缺陷导致的问题。
事故的事后分析不可以简单地归结为根源问题分析。为什么这么说？
因为通常根源问题通常就是我们分析问题停下来进行不下去的地方，再往下分析太困难了，所以就认为这个就是故障的根源了。还有一种情况是因为分析到这一步发现的问题和之前的某次故障类似，就懒得分析下去了。
故障不应该像根源分析那样，把故障原因看成一根线性的因果逻辑链条，像多米诺骨牌那样寻找第一个倒下来的骨牌。我们应该把故障看作是一个系统的多个独立的因素的共同作用导致的，应该看作一个网，网上多根线的复杂的关联的影响最终导致了故障。
第五条：软件开发人员不管运维
开发团队不管运维，割裂了开发和现实运行环境之间的联系。如此一来，开发团队就没法快速从客户反馈那里学习，并快速迭代产品。
有时候问题并不是部署或基础设施的问题。因此开发团队必须on-call，这是开发团队每个成员的共同责任。
第六条：运维不需要英雄
系统出了故障，运维人员救火成功。这其实并不是什么好事。
运维并不只是救火，未雨绸缪才更重要。
预防性维护比事后救火好得多。
就像疾控中心CDC，控制得好，就是善战者无赫赫之功。
在公司中，应该表扬通过日常工作提高系统的可靠性、弹性、伸缩性的工程师，而不是救火的工程师。
第七条： 监控系统的目的不是用来不断发送告警
要设计一套监控/日志的服务，能够稳定的输出各类通知给相应的运维人员。
监控系统不是用来不断发送告警的。
当系统规模不断增长时，告警数量不能线性增长。如果线性增长，意味着运维人员也要线性增长。
为了在系统增长十倍百倍时，不用招聘十倍百倍的运维人员，告警就不能超过线性增长。
为了实现这个目标，只能发送影响用户体验的告警和那些单点故障的告警。集群子节点的故障可以优先级低一点。
系统停机停服务，需要立马寻呼找人处理。不能自动解决的严重程度低一些的问题，就自动创建故障工单。其他更轻点的故障，则自动进入日志系统。
很多公司喜欢用电子邮件发送告警。这样做不好。不要用电子邮件发告警。电子邮件适合给同事或客户发送高价值的需要采取行动的信息，比如会议邀请或者公司放假通知。
第八条：用高级配置工具提高效率
你要是只有几条狗，你可以每天牵着几条绳出去遛狗。
要是有成百上千条狗，就需要请专门的遛狗机器人帮你遛狗，这样你就轻松了，而且成本比请人遛狗成本低。
同样道理，当你只有几台服务器的时候，你可以自己运维管理配置变更。
当你有成百上千台服务器需要管理时，就需要用如Puuppet、Chef、Ansible之类的配置管理工具来管理了。
第九条：运维不能成为开发部署的减速带
服务器和软件多了之后，避免不出故障是不可能的。系统出现问题70%是由于发生了变更。
而软件升级部署新版本就会带来变更。
但是运维运维人员不能成为开发部署的减速带。
运维人员不能因为升级部署新版本容易带来故障，就抵制反感升级部署。
因为运维人员除了保障系统可靠性外，还有一个重要任务是保障和提高开发的新版本的部署速度。而这两者之间其实并不矛盾，两者是相辅相成的。
为什么这么说？
因为可靠的系统会提高开发部署速度，而开发部署流水线顺畅快速的话，也会带来可靠性。
第十条：设计检查点
对于产品设计的每一个决策，运维团队最好应该参与。
但是每次都参加，运维人员就会很忙。
因此需要在产品设计的关键检查点参加。
第十一条：大棒不能比胡萝卜多
不要强制要求运维团队使用何种工具。
应该让运维团队自己选择趁手的工具。
这样他们会做得更好。
第十二条：不要推迟生产环境的发布
运维人员要能够让开发人员获得快速的线上的反馈。运维人员要把开发人员看作同一个战壕里的。
运维人员有时候不喜欢发布，因为发布新版本可能会带来问题。但是过于谨慎的发布会导致更大的问题。
因为发布周期过长，测试拖太久，本意是降低系统故障，但是开发人员就无法快速获得新版本功能的线上的反馈。开发人员不能快速获取线上的反馈，就需要重新去熟悉代码，开发效率就下降。
摸黑启动（dark launch）、A/B测试、灰度发布和蓝/绿部署可以给开发人员快速的线上反馈。
第十三条：提高解决高难度故障的能力
故障是在所难免的，因此需要提高解决故障的能力。
抢救病人比治未病难度大得多，消耗的资源也多得多。但是近年来，抢救技术也在不断进步。
对于计算机行业来说，也是同理。
往期精彩：
更多物联网，边缘计算相关技术干货请关注我的专栏物联网前沿技术观察
- 申请加入物联网技术研讨大佬微信群，请加微信号：iot1999。
