ING銀行はいかにSREを実践したか

ING NetherlandsのJanna Brummel、Robin van Zijll両氏がロンドンのVelocityカンファレンスで講演し、インターネットバンキングシステムの可用性の低さが同行のSRE文化導入の契機となった経緯について語った。オランダ本部にSREチームが結成され、ツーリングやコンサルティング、信頼性に関する教育をプロダクトチーム(社内ではBizDevOpsチームと呼ばれている)に提供した。

2017年中頃までのINGでは、99.99パーセントに近い理想的な可用性を備えた他システム(理想的なリテールおよびモバイルリテール)とは対照的に、インターネットバンキングのリテールシステムの可用性が96.84パーセントまで低下していることが注目されていた。このような結果をもたらした要因としては、プロダクトチームの監視オーナシップの欠如、集中アラートシステムのトリガが非常に高い(システムダウン)ために原因追求と技術者への通知に長時間を要したこと(重大インシデントで平均69分)、インシデント後のレビューと情報共有がほとんど行われていなかったこと、コンポーネントレベルでの可用性検討の欠如(結果がサービスレベルに集計されていたため、プロダクトチームが直接的な責任を感じていなかった)などがあった。

本部のSREチームの役割はコンサルティングのみ(サービスの実行や呼び出し対応は行なわない)だが、ツールや内部サービスの提供といったプラットフォームチームの役割も果たすことで、プロダクトチームによるシステムの運用と信頼性改善を支援する。チームの計画やバックログの優先度設定は、GoogleのSRE資料に定義されているサービス信頼性階層を指針として行う。

現時点では、SREチームはおもにピラミッドの下位3層を重視している。監視とインシデント応答の件については、PrometheusとGrafana、 Mattermost (ChatOps)をベースとした共通ツールを構築中である。また、プロダクトチームによる事後検討を推奨するとともに、信頼性問題の特定および修正方法に関するコンサルティングを提供している。Brummel、Zikll両氏は、重大インシデントを非難する既存文化を排除するために、多くの時間と努力を要したことを報告した。氏らのアドバイスは、インシデントレビューの頻度を実際に増やす前に、時間をかけて意識の向上と環境設定を行う、というものだ。さもなくば逆効果になる可能性がある。

これらの変更は“ビッグバン”的なイニシアティブではなく、すべて必要に応じて展開され、SREチームが提案するツーリングとプラクティスに切り換えるかどうかの決定は、プロダクトチームに委ねられた。またSREチームは、数名の技術者からなるひとつのチームから、より大きなプラクティスのコミュニティ(国をまたいだ複数のSREチーム – 現在はオランダに3、スペインに1、オーストラリアに1)へとスケールするプロセスの途上にある。SREの話題に関するデモや内部議論が、コミュニティ形成に役立っている。

両氏がSREでの取り組みから得た成果は、現在のところ次のようなものだ – 雇用時に特定スキルよりもSRE的価値観を評価すること、プライオリティ上の競合からSREチームを守るためにプロダクトオーナが必要であること、プロダクトチームにSREを説明および促進するために多くの時間を割く用意をすること、提供するツールはユーザビリティの面で商品レベルの品質を備えた、ユーザの実際の苦痛を緩和するものであること、ツーリング戦略においてスケーラビリティとオーナシップを考慮しておくこと。