当前位置: 首页 > Linux

【译文】MyLessonsonSiteReliabilityforSomeoftheWorld'sBusiestGamblingSites-1

时间:2023-04-06 19:58:44 Linux

原文:ThingsILearnedManagingSiteReliabilityforSomeoftheWorld'sBusistedGamblingSiteshttps://zwischenzugs.wordpres...多年来我为许多世界上最繁忙的赌博网站管理三级站点的可靠性运营,为一家小型知名公司的多个业务构建和运行核心后端在线软件,每个业务的峰值都在数千万英镑每小时。我几年前离职了,所以现在是反思我从中学到的东西的好时机。在很多方面,我们做了我们现在称之为SRE的事情)(我会称我们为SRE人,但当时没有这样的东西)。我们接听电话,我们需要处理故障,我们提供重构方面的意见,我们就高可用性向开发人员和客户团队提供建议,我们处理扩展和紧急情况,我们运行监控系统,等等。我加入的团队有5名工程师(都是前开发人员和技术主管),到我离开时,团队已经发展到大约50人,分布在许多地方。我会专注于过程和文档,尽管我认为它们说的不够有用,但我当时确实阅读了它们。如果你想了解更多关于谷歌SRE(https://landing.google.com/sr...)的书籍有很好的内容。ProcessFlow是操作和扩展SRE操作的核心。它是我们档案的核心。当我加入团队时,习惯不是很好——有一个票务系统,但处理日志的方式很不寻常(“站点已关闭。修复它,将其关闭”)。SRE操作基本上和工厂流水线一样,需要按照标准进行。你不会有计划外的工厂流程来处理货物的移动,就像你不会在知识敏感的SRE操作中有流程来处理知识流一样。我听到的最常见的反对过程的反对意见之一是“它会扼杀创造力”。有效的流程(糟糕的流程和糟糕的实施会把事情搞砸!)实际上会让你头脑清醒,让创造性思维浮现。这方面有一本很棒的书“清单宣言”(http://atulgawande.com/book/t...),它鼓励我们做出许多改变,并在我们小组中被广泛阅读。它举例说明了航空航天业的流程如何通过日常操作的心理自动化,在高压情况下激发不可思议的创造力。甚至有一部电影(萨利船长)讲述了飞行员在事故期间如此紧张的情况下创造性的快速思考和控制(http://www.airspacemag.com/as...)。事实上,我们自己也采用类似的流程:在紧急情况下,经验丰富的工程师努力寻找解决方案,而相对初级的工程师则根据检查表进行跟进。另一个反对流程的理由是它会干扰有效的工作和协作。如果它被视为一个独立存在的实体而不是一个生物实体,那将是可能的。我唯一可以捍卫它的是文化。待会儿再聊。过程-工具使事情正确的第一种方法是票证系统。与监控解决方案一样,对于哪种票务系统最好也存在争议。那是错误的。对于票务系统,人们最终会选择熟悉的,因为它简单。票证系统只有在驱动或鼓励不良流程时才是不良的。什么是糟糕的流程取决于您的业务限制。另一个重要的一点是,您需要一个可靠的票证系统来支持您的流程,而不是被其他方式绕过。例如。在我任职期间,我们从RT迁移到了JIRA。JIRA提供了很多RT所没有的优势,我通常推荐将JIRA作为协作工具。我们在迁移过程中遇到的最大问题是缺少一些RT功能,这对我们来说非常重要。RT使我们能够获得工单的实时更新,这意味着在事件协作方面,我们几乎处于聊天和工单之间。该记录在追溯过程中很重要。在RT中,我们可以对客户端隐藏条目,这个功能也不能丢失。我们已经解决了,但这些事情很重要,因为它们融入了我们的流程和文化。选择和切换工单系统时,请仔细考虑哪些操作真正重要,而不是只看功能列表上的内容。对你来说真正重要的不是它看起来有多好(说真的,你的客户会更看重你的品牌,你的品牌可能是一个好的设计),而是报告工具的强大程度。文档是流程之后最重要的东西,两者密切相关。有一本关于文档的书,但话又说回来,人们关注的是错误的东西。了解文档就像任何其他资产一样。文档,就像任何企业资产一样:如果维护得当,多年后就会有回报需要努力维护(如工厂基础设施)如果过时(如过时的库存)会花费金钱但这很好——几乎没有人不同意文档是有用的。问题是:你应该做什么?文档-目前的情况我们现在处于文档对我们无用的情况(例如开发人员说:'这里不太可能,所以没有处理网络分区情况'。然后,想想发生了什么!这就是他们会写在文档上),或者我们只是依靠以前的文档(这次我们写了一些东西)来研究下次遇到同样的事情应该怎么做。这让我们很沮丧,我们花了很多时间抱怨为什么在我们负责文档之前文档没有送到我们这里。文档-我所做的这就是我所做的。我花了两年时间梳理了高优先级的事件(比如已经触发——或者将要被处罚——超时的调用)并列出来。大约有1700例。然后我按类型组织它们。然后我经历了每一类问题并整理出解决它所需的步骤,或者升级它所需的步骤。这花了我七个月的全职时间。我是高级员工,我花公司的钱坐下来写。我有一个好老板,而且从来没有人质疑我时间的价值。我非常信任(再次强调文化!),以至于我在头4个月内看不到这项工作的任何结果。我记得有四个月的时间很迷茫,我不是在做日常操作,是不是在浪费我的时间和薪水,导致尴尬的失败。你为什么不放弃?有几个原因。这很重要,我们以前从未这样做过,所以我需要知道这是正确的做法。我确切地知道需要什么,所以我知道我可以把它写出来,它最终对我有用。我是一名具有相关经验的作家(艺术专业毕业生,前记者),所以我想这也有助于我写出好东西。根据ITIL,我们称这些为“失败模型”,但我们也称它们为“运行手册”、“婴儿床单”,无论它是什么都没有关系。重要的是:它们很容易找到/搜索很容易确保您得到匹配的东西他们没有副本他们可以信任我们将这些文档写成文本并将它们放在票务系统中,a单独的JIRA项目。文档团队发现了这一点,并试图让我们通过内部wiki来做到这一点。我们拒绝了,这很重要,文档系统与票务系统的集成意??味着搜索和更新文档时没有阻抗不匹配。而且因为它是简单的文本,所以它快速、易于更新且整洁。我们拒绝损害我们正在做的事情的过程。