I＆O部門の変革に向けた新たなアプローチ「SRE」

　DXを背景に企業システムのモード1からモード2へのシフトが進む中、従来業務からの脱却がインフラストラクチャとオペレーション（I＆O）部門に迫られている。その意味するところはIT基盤の“お守り”から、ITによる“ビジネスの支援”へのシフトだ。

　その対応に向け注目を集めているのがアジャイル開発手法のDevOpsである。DXでのシステムの継続的な改善は、言葉にすると簡単だが、未来が予測しにくい中での実践は極めて困難。対して短期間に小規模開発を繰り返すDevOpsであれば、プロジェクトの目的が定められている分、I＆O部門にとっても馴染みやすく、それだけ円滑な従来業務からの脱却が可能となる。

　だが、そこには1つの大きなジレンマが存在する。その点について、「そもそもI＆O部門はDevOpsに触れる機会が乏しい。それを待っていてはいつまでたっても必要なスキルセットやマインドセットを習得できず、DevOpsに乗り出せないのだ」と指摘するのは、「Gartner IT Symposium/Xpo 2020」に登壇したガートナーでリサーチ ディレクターを務める阿部恵史氏だ。

　この問題に対し、阿部氏は1つの打開策を練ってきたという。それが、DevOpsよりも運用寄りで、I＆O部門にとってDevOpsよりも馴染みやすい開発や運用の方法論の「SRE（Site Reliability Engineering）」の活用だ。「SREはDevOpsと同様の効果をI&O部門にもたらし、Dev抜きにDevOpsを目指せる」（阿部氏）というのが、その理由である。

　ガートナーの定義によれば、「SREとは、回復力の高い分散システムを構築・運用するために使用される、システムおよびソフトウェア・エンジニアリングの複数の原則から成る方法論」である。近年になり利用が急拡大しており、ガートナーの調査では海外の大企業の41％がすでにSREを採用。国内でもメルカリやクックパッド、ビズリーチなど、クラウド・ネイティブ企業や先進企業を中心に利用が加速中だ。


　最終的な狙いは「ユーザーの満足度向上」にある。そのための運用の迅速な改革や、効率的なオペレーションとバランスを取った上でのサービスの進化が主要な活動となる。

　SREチームの具体的な業務内容は「インシデント管理」「問題管理」「オペレーション」など、一見すると従来からのシステム管理者が担う業務と変わりはない。ただ、「すべてにソフトウェア・エンジニアリングを活用する点で一線を画す」と阿部氏（図1）。

SREについて押さえておくべき4つの特徴

　そして、一連の業務を概観すると、次の4つが特徴として挙げられるという。

　1つ目が、「トイル」の削減のための取り組みだ。トイルとは人手で繰り返し行う自動化の余地がある作業のこと。SREではイノベーションのための時間捻出に向け、トイル対応時間を全体の50%以下に抑制することを目指す。

「そのために、まず、構成管理でのプロセスや監視の相関分析などの自動化の仕組みを考える。次に、ソフトウエア・エンジニアリングにより設計からプログラミング、バージョン管理を行い、そこでの知見をチーム内外と共有し企業組織全体の自動化レベルの底上げにつなげるのだ」（阿部氏）

　2つ目が、「SLI（Service Level Indicators）」と「SLO（Service Level Objective）」だ。前者は顧客へのインパクトをサービス・レベルとして計測するための指標であり、後者はSLIに基づいて計測されるサービス・レベルの目標値やその範囲を指す。

「サービス品質が必要以上に高すぎたり、逆に低すぎたりしないようSLIとSLOで確認する。SLIがSLO未満かつ下限値と上限値の間に収まっていれば適切と判断される」（阿部氏）

　3つ目が、「エラーバジェット」の適切な設定だ。これは、「完璧を目指したSLOの設定は間違っている」との考えに基づくものである。たとえば、99.99％の稼働率を目指すと、月当たりのダウンタイムはわずか43分となり、この間での機能拡張や品質改善の作業は現実的に難しい。だが、99.9％であれば216分の時間を確保でき、作業の余裕が生まれる。継続的な改善に向けて全社システムに対してこの考えを広げるのである。

　4つ目が、「ポストモーテム（事後検証）」の徹底だ。柱となる活動が、インシデントの徹底的な文書化と、文書に基づく後日のメンバー全員でのレビュー、結果のチームを越えた共有によるポストモーテム文化の導入／定着だ。

「グーグルでは過去の事例を基にロールプレイングを実施し、ポストモーテム文化の定着のみならず業務品質の向上でも成果を上げている。情報共有のメリットの大きさから、企業を問わず同様の活動に取り組むべきだろう」（阿部氏）

【次ページ】SREとDevOpsの共通点と異なる点