荷兰银行的SRE实践
来自荷兰国际集团（ING）的Janna Brummel和Robin van Zijll在伦敦Velocity大会上分享了他们是如何通过SRE来提升网络银行可用性的。他们组建了一支SRE团队，为产品团队（在内部被称为BizDevOps）提供有关可靠性的工具、咨询和培训。
ING的2017年中指标表明，他们的个人网上银行系统的可用性降到了96.84%，而其他系统（如个人移动银行）的可用性都在99.99%左右。造成这种局面的因素包括：产品团队缺乏监控；集中式的告警系统只在发生重大事件（比如系统崩溃）时才会发出告警，诊断问题需要很长时间（一个主要事故平均需要69分钟）；缺少事后的事故评审和总结；缺少组件层面的可用性洞见（服务层面的反馈对产品团队来说不够直接）。
集中式的SRE团队只提供咨询（他们本身不会参与轮班待命），同时他们作为一个平台团队，也为产品团队提供工具和内部服务，帮助他们提升系统的可靠性。他们根据谷歌SRE手册中定义的服务可靠性层级来计划和安排产品团队的任务优先级。
目前，SRE团队主要覆盖金字塔的底下三层。在监控和事故响应方面，他们基于Prometheus、Grafana和Mattermost（ChatOps）构建了一些工具。他们帮助产品团队进行事故的事后诊断，并提供建议用于识别和修复可靠性问题。Brummel和van Zijll分享了他们是如何花时间和精力扭转之前那种糟糕的局面的。他们建议在增加事故评审频率之前先要多花一些时间搞清楚状况，否则可能会事与愿违。
这些变更是以逐步按需的方式推出的，而不是采取“大爆炸”式的方式进行，让产品团队来决定是否采用他们提供的工具以及是否实践他们的建议。SRE团队也在从由几个工程师组成的小团队发展成更大的社区（跨国的SRE团队，目前有三个SRE团队，分别在荷兰、西班牙和澳大利亚）。他们通过演示和内部讨论来发展SRE社区。
Brummel和van Zijll关于SRE之旅的要点包括：在进行SRE招聘时更注重SRE思维；为避免出现优先级冲突，SRE团队需要一个产品负责人；做好花大量时间向产品团队解释和推广SRE的准备；工具需要提供商用级别的可用性，而且要切实解决用户的痛点；考虑工具的可扩展性和所有权问题。
查看英文原文：How ING Bank Does SRE
评价本文
- 编辑观点
- 主编观点
提交
提交
相关赞助商
社区评论
赞助商链接
