运维团队能从橄榄球教练身上学到什么?

服务器      不久前看到一条微博,说的是一个团队去黄山集体旅游,但是为了防止网站出现突发问题,负责运维的同学还要背着沉重的笔记本电脑上山下山。运维人员确实总是要面对巨大的压力,但是是否有一些方法可以缓解这些压力呢?         Quora的工程师Edmond Lau提出了一些解决方法。Edmond Lau是Quora的元老级工程师,他曾带领工程团队应对用户的高速增长,开发核心组件,并为新入职的工程师提供指导和入职说明,同时协调工程实习计划。此前,他曾服务于Ooyala的视频分析团队和Google的搜索质量团队。不久前,他在自己的博客上发布了一篇文章《成功剧本——关于工程,我们从橄榄球教练身上能学到什么》。         文章开头,他假设了一个场景:作为一名工程师,在凌晨3点收到网站的自动提醒,原来是主数据库出了问题。接下来,他说道:传呼式职责轮换,就是说工程师轮流承担一线运维职责,应对当周所有与网站相关的警告,这是互联网产品增长阶段要应对的最具压力的经验之一。随时听从召唤,意味着你不论去哪里,都必须让笔记本电脑放在手边,而且随时都可能处理问题,有时处理的是小问题,但有些时候,面对十分严重的问题,而且需要尽快解决。但他提出一个问题:即使这种分担职责的方式十分重要,我们能做些什么改善这种情形吗?还有那些必须要在压力和不理想环境下处理完善的情形呢?接下来,他认为可以从橄榄球教练身上吸取一些经验。 Edmond引述了旧金山49人队前任教练Bill Walsh的一个策略“成功剧本”,应用这种策略,Walsh会针对各种比赛中可能发生的情况,写下应急计划。在他看来,Walsh认识到一点:在面对比赛关键时刻时,可能有成千上万球队的粉丝朝你狂吼,对手的球迷也在朝你扔热狗和塑料啤酒杯,宝贵的时间在一分一秒地过去,这时的你很难保持清醒头脑,做出有效决策。         Walsh认为:在面对高度紧张、精神难以集中的比赛时刻,写下剧本有助于去掉制定决策过程。当时没有其他队伍这么做,这种做法让我们占有了令人惊叹的战术先机。不管境况优劣,写剧本都是最有效的领导工具。这种精明的方式,让我在比赛还没有开始前就已经掌控了比赛。我发现这种方法后,其他球队用了好多年才完全推广开这个理念。Walsh最终带领49人队获得3次超级碗胜利,并两次获得NFL年度教练称号。         Edmond认为:我们可以采纳Walsh的写剧本策略,将决策制定过程从高压或是高风险情形转移到更受控的环境中。以此,就可减少感情蒙蔽我们的判断,或是时间重压在我们头上之类的状况。作为工程师,我们甚至可以编写程序剧本,模拟我们的响应,还要测试,以保证剧本足够健壮。在Edmond看来:这在大型工程组织中尤为重要,因为任何可能出问题的基础设施都会出问题。接下来,Edmond列举了一些大型技术公司的例子,说明他们如何在正常时期模拟系统失败和灾难,以应对非常情况:         2006年时,我还在Google工作。Google每年都有持续多日的“灾难恢复测试(Diaster Recovery Testing - DiRT)”活动。在DiRT演练中,公司会模拟诸如地震、飓风之类的灾难,并验证在断电或者整个数据中心或办公室出现故障中,团队、沟通和关键系统能否保持正常运转。这个演练会发现单点故障、不可靠的故障切换、过时的应急计划、或是其他没有预料到的错误,还能帮助团队在受控环境下处理这些问题,同时没有在真正的紧急时刻面对的恐慌和压力。         Netflix构建了Chaos Monkey系统,可以随机关闭自己基础设施中的服务。直接宕掉自己系统中的服务,这看起来好像有违常理,但是他们的配置可以在平时的正常工作时间杀掉服务,工程师因此可以在办公室里面直接发现架构上的问题,而不是在半夜被叫起来。他们在博客上这么说:“应对重大未知失败的最佳防守,就是经常失败。”         Dropbox的工程团队常常为自己的系统增加额外模拟负载。如果他们发现某些系统达到极限、出现问题,他们就能关闭模拟负载,解决问题。相比面对真实的生产环境再去救火,这样的压力要小得多,毕竟生产环境的流量无法直接关闭。         Edmond对上述例子做了总结:工程组织会假设不可预期和不希望的事情总会发生,他们的策略是:在正常时期,最好先针对这些情况做规划、写剧本,而不是等到事情不可控制时再去处理。即使与基础设施不相干,在我们的职业生涯中,也会遇到其他高风险、高压力的事情,比如面试、工资协商等等,没那么频繁,但是充满压力,而且影响深远。针对这些情形,写剧本、做准备,是事半功倍之事。   在文末,Edmond列出了一些参考文章,包括
  1. Google的Kripa Krishan在ACM期刊上发表的《经受不可预期的考验》
  2. Netflix的John Ciancutti在Netflix技术团队博客上发表的《我们使用AWS得到的5个教训》
  3. Netflix的Cory Bennett和Ariel Tseitlin在Netflix技术团队博客上发表的《放到野外的Chaos Monkey》
  4. Dropbox的Rajiv Eranki发表的《在Dropbox学到的扩展经验,第一部分》
  5. 《成功剧本——关于工程,我们从橄榄球教练身上能学到什么》
  6. 那些年我们犯过的错(一)—— 豆瓣Xupeng:补齐那丢失的三分钟数据
  7. 如何恢复丢失的两个月数据 —— “下厨房”技术团队分析总结6.26数据库事故
  如果他们事先能够写写剧本,也许就可以避免遇到的严重问题,那个背着笔记本电脑上山的苦逼运维也许就可以放下电脑、放下压力、放下心情,放心轻松了。

你可能感兴趣的:(工作,人生,运维,态度,转贴)