• 会員限定
  • 2021/01/06 掲載

SREとは何か?DevOpsと何が違う?ガートナーが解説する運用管理変革の現実解

  • icon-mail
  • icon-print
  • icon-hatena
  • icon-line
  • icon-close-snsbtns
記事をお気に入りリストに登録することができます。
開発速度を高めるアジャイル開発の方法論であるDevOpsが、インフラストラクチャとオペレーション(I&O)部門から注目を集めている。背景には、DevOpsの利用が、いち早い変化対応に向けたスキルセットやマインドセットの獲得の近道と目されていることがある。ただし、そこで壁となっているのが、DevOpsに取り組むには従来とは異なるスキルが必要となることだ。この課題克服に向けた“解”となりそうなのが「SRE(Site Reliability Engineering:サイト・リライアビリティ・エンジニアリング)」だ。ガートナーでリサーチ ディレクターを務める阿部恵史氏が基礎からわかりやすく解説する(2021年11月1日一部更新)。

解説:ガートナー リサーチ ディレクター 阿部恵史氏

解説:ガートナー リサーチ ディレクター 阿部恵史氏

これまで25年以上にわたって積み上げてきたIT業界でのキャリアを生かし、ガートナー ジャパンにおいては、ITオペレーション分野を中心とした市場動向分析と提言を行っている。
ガートナー ジャパン入社以前は、国内・外資系ベンダーにおいて、製品/ソリューション・マーケティング、製品マネジメント、デジタル・マーケティング、イベント、チャネル、広報、アナリスト・リレーションなどの各種マーケティングや新規市場開発業務を担当。また、業務系システムの設計・開発・サポート、インフラ系のシステム・コンサルタント、バックライン・サポートのエスカレーション・エンジニアなど技術系の職種も多数経験。
ビジネス・ブレークスルー大学大学院経営学修士課程修了 (MBA)。
(プロフィールはガートナー公式サイトより引用)

画像
SRE(Site Reliability Engineering)とはいったいどういう概念なのか?
(Photo/Getty Images)


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とは?
サイト・リライアビリティ・エンジニアリング (SRE)とは、回復力の高い分散システムを構築・運用するために使用される、システムおよびソフトウェア・エンジニアリングの複数の原則から成る方法論のこと
(出典:ガートナー)


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

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

画像
SREで実施項目はシステム管理者のものと一見、変わらないが、すべてにソフトウェア・エンジニアリングを活用する点で大きく異なる。

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の共通点と異なる点

画像
SREのスキルセットとは?(次ページで詳しく解説します)

関連タグ

関連コンテンツ

あなたの投稿

    PR

    PR

    PR

処理に失敗しました

人気のタグ

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

必要な会員情報が不足しています。

必要な会員情報をすべてご登録いただくまでは、以下のサービスがご利用いただけません。

  • 記事閲覧数の制限なし

  • [お気に入り]ボタンでの記事取り置き

  • タグフォロー

  • おすすめコンテンツの表示

詳細情報を入力して
会員限定機能を使いこなしましょう!

詳細はこちら 詳細情報の入力へ進む
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます