
28
|
第
1
章
如果你能做的仅仅是帮助它成长。不过通常情况下,为了在成长过程中,不断地应
付那些累积的技术债务,人们会有比想象中更多的选择。
注
20
毋庸斟酌是否,只需推敲时机
然而,当你的组织或产品增长到超过一定规模时,在支持哪些产品、支持优先级的
分配等方面,你就有更大的自由度了。如果,对系统
X
提供支持的时间比系统
Y
更
早是已经确定了的,那么在
SRE
的世界里,就相当于在说先不支持哪个服务了。
在
Google
,
SRE
与产品开发团队的紧密合作关系已被证明至关重要:如果你的组织
存在这种关系,那么回撤(或提供)支持的决策可以基于运维方面比较客观的数据,
从而避免一些无谓的讨论。
SRE
与产品开发团队之间富有成效的合作关系,也有助于避免产品开发团队在产品
或特性在未准备就绪前,就不得不交付出去的组织层面的反模式。相反,
SRE
可以
与开发团队合作,赶在维护产品的重担离开拥有最多专业知识的开发团队前,产品
就得到了良好的优化。
尽量在职业发展和物质激励上一视同仁
最后,为了确保职业激励机制能指引人们做正确的事情,我们希望
DevOps/SRE
部
门与对应的产品开发部门都要得到同等的尊重。因此,无论是哪个团队的成员,都
要按照大致相同的方法进行评级,且予以相同的物质激励。
小结
在整个
IT
运维领域里,
DevOps
和
SRE
在许多方面都非常接近,包括它们的实践和
理念。
DevOps
和
SRE
都需要一线工作者、实践者进行讨论、参与管理、提供支持,这样
才能取得重大进展。践行其中的任何一项都是一段旅程,没有解决问题的捷径:那
注
20
:
有关如何在不同背景下应用 ...