SRE的完全体：左手效率，右手容灾

mujingluo

于 2024-10-10 00:48:33 发布

阅读量570

点赞数 23

文章标签： SRE

本文链接：https://blog.csdn.net/mujingluo/article/details/142768123

版权

什么是SRE

共和国的75周岁之际，重温了我心中的经典电视剧《人间正道是沧桑》和小说《远东朝鲜战争》，在看到剧中杨立青在东北战场被任命为“特别部部长”的情节，以及志愿军总后勤部的成立过程及洪学智将军后勤工作的历程时，突然有了同频共鸣——这不就是红色版的“SRE”嘛。

剧中杨立青面对的情形是我方实力爆发式增长，东北战场敌我实力呈现逆转趋势，作战方式也由游击战转向了大兵团运动战，但却接连出现作战失利，主要原因是广大将士还停留在过去的“野路子”游击战视野中，在新的大兵团作战体系中，以往无往不利的游击战思路成了胜利的绊脚石，解决痛点成为了迫在眉睫的事情。——这像不像过去互联网十年的许多公司的样子。

杨立青用了短短数月，梳理解决了铁路运输问题、各部门的职责划分问题、战争资源（主要是大炮分配和炮弹制造）问题，将现有资源进行了盘活，彻底激活了东北解放军的战斗力。而在数年后的朝鲜战场，面对存在代差的联合国军，脆弱的补给线成了志愿军的致命软肋，临危受命的洪学智将军以补给线为基线，从源头到战场，统筹包括兵工厂、铁路、公路、防空、工程等所有资源，甚至对各部队的武器进行了重新洗牌（志愿军各部队的武器型号五花八门，把正确的弹药送到正确的位置成了几乎不可能的事情，志愿军后期对武器进行了重新分配，某一类口径的武器只装备某些部队，只需要知道部队番号就能知道配送什么弹药），从效率到保障，建立了一只可靠持续的后勤补给线。

历史与现实交汇，关于什么是SRE的问题，共和国的先驱们已经给了一个标准答案。

如何做好SRE

有些人说SRE是懂开发的运维，有些人说SRE是会运维的开发，但不可否认的是，SRE的诞生来自于程序员与运维在业务爆炸增长中激化的对立矛盾（程序员是在做加法，运维是在做减法），我的认知中，SRE不是程序员或运维的变种，而是一种全新的“兵种”，程序员是执矛兵（代表效率），运维是执盾兵（代表容灾），SRE就是左手执矛，右手执盾的斯巴达勇士。

做一个社交达人

我的职业领路人有过一句话——“键盘敲的啪啪响的不是好运维”，在他的影响下，我的职业生涯几乎一半的时间用来去各个部门交朋友，所以我的工位经常是无人状态，但工作效率和质量却有增无减，通过与业务部门频繁的交互，我总能第一时间获取最原始的需求，以及察觉最真实的风险。这种觉悟跟能力也成为了我后来转为SRE的关键。

抛弃原有思维

SRE的主要来源是资深程序员和资深运维，但因职业特性，程序员和运维通常都更喜欢跟代码和机器打交道，在以往的职业中，这或许不是缺点，但在SRE中，这无疑成了缺点。
我就职过的A公司的运维团队就是典型的程序员风格，迷信代码的力量，对需求和问题统统能用代码解决就用代码解决，我入职后面对就是被扔在角落吃灰的自研运维管理系统、臃肿且脆弱的发布系统、问题频出的线上服务，自研运维平台系统是一味模仿外面，追求大而全，却忽略了内部实际需求，导致几乎无人愿意使用；而发布系统在一开始就对所有个性化需求来者不拒，导致程序逻辑十分复杂，一个小组件故障往往会导致整个系统不可用，后期一个很小的需求，都需要费很大的力气才能够解决；而线上服务不稳定的根本原因竟是为了达成成本优化，不是去做容量规划，而是另辟蹊径选择超发使用资源，导致经常出现资源争抢问题引起服务漂移重启。

我就职过的B公司则是典型的传统运维风格，领地意识比较严重，只要自己不出问题就行，经常被重复的事务淹没，缺少创造性，在庞大的增量服务和复杂的架构面前，很难满足业务要求的效率。

在A公司和B公司我都进行了不同方向的针对性建设，并取得了不小的成功，但这并不是简单的纠正那么简单，而是需要不拘泥于原有思维定式，已更加全局的思维去看待事务，才能够发现痛点，解决问题。