我想之后的招聘软件上，会越来越多出现SRE这个岗位，但很可能就像是“使用tensorflow进行机器学习”的课程中所说：我们仅希望生成一个ML模型是没法真正改进自己的业务一样，最终只能面对失败。同样的，如果企业仅寄托于最原始的拿来主义，但不划清不同职责之间的工作范围、协同规则，并且无法贯彻这些先进思想的哲学思想，但我觉得也没法从根本上解决目前的问题。
这几天囫囵吞枣大概看了看SRE的理论部分，最启发自己的归纳起来就是这么一句话：要让你的工作是受策略引导的，而不是事件引导的，并且无论什么工具，最终要达到的目的都是让你的工作不随业务量的线性增长而增长。
从这句话延申，我不由得想到之前一个问题：比如我之前参与的一个以CMDB为核心的运维平台，随着需求的不断提出，致使无论是数据库表、视图，还是代码中的数据库表模型代码、服务代码、接口代码都直线增长，导致已经出现了维护的困难。并且，按照谷歌所说，真正要能做好业务，你必须用数据来驱动：你新增的这个API，上线之后使用率如何？都是谁在使用？接口调用延迟如何？失败的请求多么？我们没法知道，只能通过使用者的反馈，然后再去查日志，而且更糟糕的是，即便我对这个服务接口做了改进，那这个改进只是针对这个接口而言，我们没法把这个优化应用到已有与将要开发的需求当中
同时，在这几章理论知识中，也提到一点，就是每个人做的事情：开发的功能、提的变更、修复的bug都应该是能追溯的到，要重视“配置文件”。
这点是被我们忽略的，当然我现在也理解，因为也就是SRE在toil那节说到的“恶性循环”：突发的非策略事件，突然发生你必须处理，处理完了如果不控制这种事件发生的频率与数量，那么很快就会占满你所有工作时间。
同样的，如果你忽视这些paperwork --> 协作时容易因为无法追溯而花费更多时间 --> 本来的研发任务就会受到影响 --> 不写配置文件或变更文档 --> 恶行循环
总而言之，这本书对于我在之后的运维开发工作大有裨益，让我更深刻理解到，工程师工程师，最重要的是要站在工程的角度去解决问题。我们需要提升自己的算法能力，需要提升自己并发编程的代码水平，但更重要的，是要去思考，自己一直的workflow是否存在不规范工程的问题
这里还有一篇知乎专栏上的文章介绍这本书
https://zhuanlan.zhihu.com/p/22354002
