谷歌SRE理论读书札记:回顾理论与实践

阿里云双11来了!从本博客参与阿里云,服务器最低只要86元/年!

我想之后的招聘软件上,会越来越多出现SRE这个岗位,但很可能就像是“使用tensorflow进行机器学习”的课程中所说:我们仅希望生成一个ML模型是没法真正改进自己的业务一样,最终只能面对失败。

这几天囫囵吞枣大概看了看SRE的理论部分,最启发自己的归纳起来就是这么一句话:要让你的工作是受策略引导的,而不是事件引导的,并且无论什么工具,最终要达到的目的都是让你的工作不随业务量的线性增长而增长。
从这句话延申,我不由得想到之前一个问题:比如我之前参与的一个以CMDB为核心的运维平台,随着需求的不断提出,致使无论是数据库表、视图,还是代码中的数据库表模型代码、服务代码、接口代码都直线增长,导致已经出现了维护的困难。并且,按照谷歌所说,真正要能做好业务,你必须用数据来驱动:你新增的这个API,上线之后使用率如何?都是谁在使用?接口调用延迟如何?失败的请求多么?我们没法知道,只能通过使用者的反馈,然后再去查日志,而且更糟糕的是,即便我对这个服务接口做了改进,那这个改进只是针对这个接口而言,我们没法把这个优化应用到已有与将要开发的需求当中

同时,在这几章理论知识中,也提到一点,就是每个人做的事情:开发的功能、提的变更、修复的bug都应该是能追溯的到,要重视“配置文件”。
这点是被我们忽略的,当然我现在也理解,因为也就是SRE在toil那节说到的“恶性循环”:突发的非策略事件,突然发生你必须处理,处理完了如果不控制这种事件发生的频率与数量,那么很快就会占满你所有工作时间。
同样的,如果你忽视这些paperwork –> 协作时容易因为无法追溯而花费更多时间 –> 本来的研发任务就会受到影响 –> 不写配置文件或变更文档 –> 恶行循环

总而言之,这本书对于我在之后的运维开发工作大有裨益,让我更深刻理解到,工程师工程师,最重要的是要站在工程的角度去解决问题。我们需要提升自己的算法能力,需要提升自己并发编程的代码水平,但更重要的,是要去思考,自己一直的workflow是否存在不规范工程的问题


TB12yaCKpXXXXa.XVXXXXXXXXXX_!!0-item_pic.jpg

实践部分

通过时序数据进行告警的实践

Practical Alerting from Time-Series Data

https://www.jianshu.com/p/b6e4b1295ea8

Python量化投资网携手4326手游为资深游戏玩家推荐:《《妖恋奇谭:光芒》“试炼空间”活动开启

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论