运维全球最大游戏网站过程中积累的SRE经验
|
为什么不交给初级员工来做?有几个原因.这件事太重要了,以前从未做过,因此我需要自行确认具体做法是妥善无误的.我完全清楚自己需要什么,因此亲自做这事至少可以确保能得到对我来说最为有用的结果.我本人也是一个有经验的作者(艺术学院毕业,曾担任记者),因此我觉得由自己来写是一种更妥善的做法. 我们按照 ITIL 将其称之为“事件模块”,但其实也可以叫做“运行手册”、“小抄”之类的.名字不重要,重要的是：
我们将这些文档以纯文本形式保存在工单系统一个单独的 JIRA 项目内. 文档团队了解到我们的所作所为,希望通过施压让我们转为使用一个内部维基.他们的决定很快被我们拒绝,原因也很合理：文档与工单系统的共存意味着文档的搜索和更新不会遇到相互矛盾不匹配的情况.纯文本格式的内容可以用非常快速简单的方式更新,并且可以保持一切内容井然有序.他们所要求的流程会让我们当时希望打造的工具夭折,我们自然是拒绝的. 文档和整理工作的关键性 最开始我们为这些事件模块设计了一种架构,那是一种很美观的架构,涵盖了可能出现的所有场景和情况. 但最后发现这完全是浪费时间.最终我们使用的是一种非常愚蠢的结构,其中包含：
就是这样.希望彻底改进结构的企图完全失败了,也许因为新的结构会让新人感到困惑,会给管理人员造成太多负担,或覆盖面还不够广.一些条款会随着时间的流逝形成与具体任务更匹配的专有架构,新的分类(例如“跳转”条款可以告诉你需要参阅哪些条款)也会随着时间流逝逐渐完善.我们并未提前设计好这些东西,因为我们不知道到底什么是可行的,什么又是不可行的. 如果愿意,可以将其称之为“敏捷文档”,敏捷是目前的热门(以前最热的是 ITIL).当然,重点在于 简化和实用性 胜过其他一切. 会写文档的田螺姑娘并不存在 在文档方面花费那么多时间和精力后,自然而然就得出了这样的结论. 首先,我们不再寄希望于接受其他团队提供的文档.如果他们给代码加了注释,这挺好；如果我们能在维基中找到对自己有帮助的信息,这也挺好.但在接手不同项目时,我们已经不再“要求对方提供文档”,相反我们会安排与负责设计项目,并且有经验的 SRE 约个时间一起讨论. 一般来说(假设没有运维经验的话),开发者往往更关注自己开发的东西及其工作原理,这些东西通常会经历彻底的测试,出错的可能性是最低的. 与之相对的,SRE 最关注弱点,以及可能出错的东西.“如果为网络划分分区会怎样?如果数据库磁盘空间不足会怎样?能否通过日志判断用户为什么没有收到钱?” 随后我们会自行编写自己的文档,并让相关工程师进行签发,这是一种与传统工作流截然不同的方法!他们通常会给出非常有用的意见,并针对整个流程为我们提供更深入的见解. 我们注意到的第二件事是,我们的工程师依然不愿意更新文档,除非是他们自己会用到的文档.然而文档依然需要交给他们处理.领导层只能不断地强调这也是工程师自己的文档,不是世代相传的石碑,如果不进行持续不断的维护,文档很快将变的毫无用处. 这其实是一种文化方面的问题,需要花费很长时间才能解决.解决这个问题还需要能通过流程强制对文档进行修订. 最后我发现,我们的日常工作中约有固定 10% 的工作时间被用来维护和编写文档.在最开始 7 个月的突击之后,这 10% 的时间主要被用于维护文档,而不是继续创建新的内容. 文档 – 收益 文档工作全部完成后,我们所获的的收益远远超过了那 10% 的工作时间.例如： 新员工更易于上手 在实施这样的流程之前,我们不愿意雇佣没经验的人员.但实施之后人员的上手过程更加顺畅了.此外事件发生之后进行的培训也逐渐培养了更多有经验的人员.新员工首先需要帮我们维护文档,这一过程也有助于他们对自己的知识和技能进行查漏补缺. 更好的培训 文档为我们提供了丰富的资源,可以帮助我们确定培训需求.进而我们可以为任何工程师提供完成工作所需掌握的工具和技术. 简化的升级上报流程有助于减少压力 这个收益非常重要.在使用循序渐进的事件模型前,何时进行升级上报是一个压力重重的决策.一些工程师因为过早升级上报而著称,大家都无法自信地确定在非工作时间联系负责的技术主管前是否“漏掉了某些显而易见的状况”.SRE 也经常因为升级上报不够及时而头疼! 事件模型解决了这个问题.很快,负责处理升级上报后问题的技术人员开始首先询问：“你是否已经按照事件模型进行过处理?”如果是,并且存在某些明显的疏忽,那么问题就变的非常明确,可以快速解决.很快,非 SRE 人员在处理过升级上报的问题之后会开始忙着更新和维护文档,进而形成了一种良性循环. 更好的纪律 对于团队来说,文档最明确的价值在于可以帮助团队改进其他方面的纪律.有趣的是,以前 SRE 被誉为“最吵杂”的团队,他们经常会进行各种“争论”,并且整个团队的社交属性十分强.这其实也挺合理,因为我们毕竟需要相互支持着才能搞定各种大型的技术领域,满足通常不具备技术背景的客户预期,而知识和文化的分享很重要. （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
