闲话IT运行—学习谷歌(Google) SRE不易

系统正常,只是该系统无数异常情况下的一种特例
          --- 摘录自《SRE Google运维解密》

近期谷歌(Google) SRE很火,大家内部给各类人都配了一本《SRE
谷歌运维解密》,希望我们能熟读,从中能取些经。

SRE的的多少个主导方法论:
1)确保运转人员长时间关切研发工作;
2)在保持服务SLO的前提下最大化迭代速度;
3)珍重监控系统;
4)应急事件处理,器重运营手册维护以及on-call机制;
5)变更管理自动化;
6)合理对急需开展前瞻和对体量举办对应陈设。
看完第一章 SRE方法论后就领会google SRE并不是那么容易学习了。

SRE是另一个很火的概念devops在google的特级实践,结合google的天性开展了伸张。在SRE的多少个着力方法论中率先条最重点,是抓实其余多少个方法论的前提和驱动力。一般运转(ops)和付出机构(dev)是单身的七个部门,那三个机关有完全区其他靶子述求,ops希望平安鳌头独占,系统上线后一百年不变才好;dev部门希望赶紧形成业务部门指出的急需,巴不得随时各处变更上线。那一个争辨导致三个机关“不对付”,是IT内部不调和声音的来自,处理不当会时有暴发严重的办公政治,对工作和团协会建设都严重有损。(那种景观可以参照运转界难得的一本小说《凤凰项目-一个IT运行的传说典故》中有关运行部门和开销机构斗智斗勇、互黑的传说,和现实中相遇的正是一样一样的,表达ops和dev的冲突和国别无关,人种非亲非故)。

Devops希望的是dev和ops尽量的玉石俱焚,一般是多少个机构尽量的融合,譬如,归属一个公司、由同样人领导、集中办公等等。google直接一步到位—dev和ops是一个人(合体了),并且SRE
至少48%生机用于花在真正的付出工作上。招聘时以开发人士的渴求来招聘SRE,SRE的招贤纳士须求标准上比平常工作开发人士还要高,既懂开发又要懂运转。那样的功利是举世瞩目标,一个人身上哪些地点疼唯有协调最了解,运营进度中的痛点开发人士是不明白的,运营人士提出来开发人士也不必然能切肉体会,做一个截然好用的运转功用出来。

后天的成本越来越多的是工作支付,不难点说是用一堆if/else逻辑驱动数据将业务逻辑完成出来,很多业务开发人士对系统的健壮性、可维护性根本不打听,也没能力驾驭,开发进度中也不会设想到(业务成效都做不完,哪还有空去考虑健壮性啊~)。这就要求运营开发人员补充进来,从系统的冗余、应急、告警、监控等多维度去给业务系列打补丁,进步系统的安静。那部分干活明日广大场合下是不足的,因为不大概直接暴发价值也招致管理层器重不够。

当运营人士有开发能力(如同一个木工有了趁手的斧头锯子),并且能有1/2上述的生命力投入到运行效率的支付中,mg游戏平台手机版,把作业系统再穿上一件运营功用(健壮性、可用性、可维护性方面)的铠甲,那么不仅会升级系统的可用性,而且可以更好的配合工作开发人士举行持续集成(CI),持续安顿(CD)这一个高阶玩法,否则系统自个儿已是弱不禁风,怎么受得了花样翻新的悲惨!

因而,想深造SRE,首先看望是还是不是达成SRE大旨方法论中的第一条,若是运营人士或许有些一味只会看看告警、查查SQL,那么很难学到SRE精髓。当然就是做不到,其余地点也得以参照学习,那本书上依旧有许多其余值得借鉴的有些,譬如方法论的第二点,制定好SLO,依照SLO决定上线频度(有理有据和付出争取不给上线:));方法论第四点建立告警监控的值班制度等等。

相关文章