BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル 本番環境の卓越性を備えた複雑システムでの持続可能な運用

本番環境の卓越性を備えた複雑システムでの持続可能な運用

原文(投稿日:2019/05/31)へのリンク

InfoQ Articles Add article Article queue List untranslated articles Navigation Main menu Logout Time is now Jun 10, 2019 22:30 on this server. Timezone: CST (GMT-6). GeneralMain contentTopics Body:Show plain editor

[Site Reliability Engineering(SRE)]および開発チームは、直面している問題に対処し、再設定が必要な問題点を特定する必要があります。SREの仕事の一部は、変化するビジネスニーズに直面しても本番環境の卓越性を維持するのを手助けすることです。SheerinらによるThe Site Reliability Workbook

コンポーネントやサービスを開発するチームが、それらのサービスに対して要求する本番環境の所有権は、高品質のソフトウェアを確保し、開発のフィードバックループを厳しくするためのベストプラクティスです。うまくいけば、所有権は、エージェンシーやインパクトの強い仕事に対する私たちの自然な欲求をもたらす力と自律性をエンジニアに提供し、ユーザにより良いエクスペリエンスを提供することができます。

しかし実際には、チームは健全であるための適切な訓練や保護がない中、いつでも電話に出れるように緊張感を持った状態となっています。チームの責任を突然変更すると、サービスの信頼性が低下し、チームが士気を失い、責任感が小さくなるきっかけが生まれます。チームメンバーは重要なスキルに欠け、追いつくのに苦労し、欠けているものを学ぶ時間がありません。問題は力を付けることがない中での責任です。問題を解決するためにお金を使うという動機があるにもかかわらず、より多くのツールを購入しても、チームの能力や構造のギャップを埋めることはできません。ツールは、新しいスキルを教えたり、現在の問題を解決するためにプロセスを適応させたりするのではなく、既存のワークフローを自動化する助けにしかなりません。

本番環境の所有権という考え方で成功させるためには、チームは生産システムを運用するのに必要なスキルを開発するためのロードマップを必要とします。本番環境の所有権だけでは足りません。私達はまた本番環境の卓越性を必要とします。本番環境の卓越性はチームが自信を持って変化する状況に適応するために使用でき、教えることができるスキルセットです。それは単純なツールでなく、人、文化、そしてプロセスに対する変化を必要とします。

 

Credit: Emily Griffin (@emilywithcurls)

 

サイロ化する業務は機能しない

本番環境所有権を実践する代わりに業務をアウトソーシングする開発チームは、業務衛生に関するインセンティブの不整合と闘うことになります。このようなチームは、操作性を損なうことよりも素早い機能開発を優先します。オペレータによる介入の必要性は、チームが提供できるよりも早く増加します。システムの稼働とスケールアップを維持する必要がある運用重視のチームは、注意散漫、夜遅く、時間外勤務などの状態にある人的コストをいくらかけても、混乱に至ります。その操作のために割り当てられたすべての人間が燃え尽きてしまうようなサービスは長い間機能し続けることができません。

 

Credit: Emily Griffin (@emilywithcurls)

 

devとopsが壁を越えて互いにコードを投げると、開発者とオペレータの両方のニーズのコンテキストを失います。リリースには手動テストが必要で、プロビジョニングには人手による対応が必要です。失敗には手動での調査が必要です。そして、複雑な機能停止では、複数のチーム間でのエスカレーションのため、解決するまでに時間がかかります。チームは、手間のかかる面倒でエラーが発生しやすい作業をするか、リスクを増幅させる不正確な自動化を開発します。たとえば、停止した理由を調べずにプロセスを再開します。この種の反復的なブレーク/フィックス作業、または労力はサービスの規模に比例し、チームの血、汗、涙を必要とします。専用のSREチーム構造を使用している組織や、より伝統的なsysadminチームを抱えている組織では、チームがすぐに業務上過負荷になる可能性があります。

時間が経つにつれて、操作性の問題によって、製品開発も遅れてくるでしょう。それは、知識とツール(devとopsの間)が分断されていると、別々のチームが本番環境での障害を容易に理解して修復することができず、修正するために何が重要かに同意できないことさえもあるためです。本番環境の所有権は理にかなっています。開発チームが運用の意思決定の苦痛を感じるようにフィードバックループを閉じ、運用の専門知識をサイロ化するのではなく、チームに持ち込むのです。

ポケットベルを配ってもうまくいきません

開発チームに電話をかけるには、それを成功させるための準備が必要です。テクノロジー企業は、専門化を通して効率性を見出すことを目指して、数十年前に運用と開発の役割を分離していました。機敏性を向上させるためにこれら2つの機能を強制的に戻すという最近のプロセスは、一晩では成し得ません。統合されたDevOpsチームが現在行うべき業務タスクは、devチームが慣れ親しんでいるスキルや直感とは異なることがよくあります。アラートの量と手動による介入は膨大な量になる可能性があります。これは、opsの作業が価値がないという見方を強固なものにします。また、アラートや手作業の量を減らすには、devとopsの両方のスキルを組み合わせる必要があるため、多くの開発者は本番環境の所有権をチームに持ち込もうとする試みに抵抗します。

多くの市販ツールは、DevOpsや本番環境の所有権の本質的な摩擦を軽減すると主張していますが、その代わりに真理の源泉をさらに分散させ、システム内のノイズを増大させます。全員を本番環境で教育し参加させるための体系的な計画がない限り、重要な問題はすべて、チーム内の数少ないエキスパートにエスカレーションされます。たとえそれらの専門家が情報を蓄えるのではなく共有しようとしたとしても、絶え間ない中断は彼らが完全な文書を書くことを妨げます。ソフトウェアの品質ではなくソフトウェアの出荷率にのみ焦点を絞っている場合、継続的な統合とデリバリの測定基準は罠になります。

 

 

Credit: Emily Griffin (@emilywithcurls)

 

システムが運用環境でどのように失敗しているのかチームが理解できない場合、インシデントを検出して修復する時間は長くなります。自信を持ってソフトウェアをデプロイするためには、チームは本番環境へのデプロイを妨げないようにする必要があります。さもなければ、変更に対する失敗率が高い環境では、チームのハードワークによりストレスの多い状況の下で繰り返しロールバックされるか、または修正されます。チームの全員に既存の運用上の痛みを分散させることはより公平ですが、運用上の過負荷からの真の救済はポケットベルアラートの数の削減とチケットの破棄/修正によるものです。

システム工学の専門化は価値があり開発に時間がかかり、歴史的に低く評価されてきました。製品開発者は、ノイズの最大の削減のためにどのような自動化を書くべきか、どのようなバグを修正すべきかを決めるための良いフレームワークを必ずしも持っていません。労力やその他の形態の業務上の債務に対処する時間があったとしても、事前に計画する必要があります。例えると、苦しい仕事は技術的債務に対する運用上の利子の支払いです。利子を単独で支払っても、未払い元本は減りません。本番環境の所有権は、無能なオペレーションチームを持つよりも優れた戦略ですが、本番環境の苦痛のレベルは変わりません。チームの役割をブレンドすることで、プロダクションの問題がより公平に分散されますが、代わりにその問題を軽減するより優れた解決策があります。顧客と開発チームの両方が、技術的および運用上の債務を返済するときに利益を得ます。

より良いアプローチ:本番環境の卓越性

本番環境の所有権の問題をツールで解決したり、チームを強制的に統合したりするのではなく、人を中心としたアプローチ、つまり本番環境の卓越性が必要です。

本番環境の卓越性は、チームが本番環境の所有権に自信を持つことを可能にする一連のスキルとプラクティスです。本番環境の卓越性のスキルはSREチームやSREの称号を持つ個人の間でしばしば見られますが、それは彼らの領域だけであるべきではありません。本番環境の所有権に関するフィードバックループを閉じるには、これらのスキルをチームの全員に広める必要があります。 本番環境所有の下では、運用は「他の誰かの問題」ではなく、全員の責任になります。 チームメンバー全員が、フルタイムで注力していなくても、運用と本番環境の卓越性に基本的に流暢である必要があります。そして、チームは、それらのスキルを磨くときにサポートを必要とし、報酬が与えられていると感じる必要があります。

 

Credit: Emily Griffin (@emilywithcurls)

 

チームとチームがサポートするサービスを長期的に予測できるようにするには、4つの重要な要素があります。まず、チームはどのようなイベントがユーザの満足度を向上させるかについて合意し、そうでないものについては無関係なアラートを排除する必要があります。第二に本番環境の健全さを探求する能力を向上させなければなりません。それには、潜在的な原因に基づく探査でなく使用者の痛みの症状から始めます。第三に、彼らが協力し、お互いに知識を共有し、新しいメンバーを訓練できることを確実にしなければなりません。 最後に、どのリスクを修正するかを優先順位付けするためのフレームワークが必要です。そうすると、顧客のニーズに対してシステムが十分に信頼性を保ち、持続的に稼働できるようになります。

1. 何が問題かを測る

通話を許容範囲内にするには、まずノイズを減らし、アラートと実際のユーザの問題との相関関係を改善することから始めます。SREプラクティスの礎石であるサービスレベル目標(SLO)は、長期的なユーザの期待に十分に応えるシステムを維持していくためのフィードバックループを作成するのに役立ちます。SLOの基本的な考え方は、失敗は正常であり、完璧を追求して開発の俊敏性を浪費するのではなく、許容できる失敗のレベルを定義する必要があるということです。Charity Majors氏が言うように、「あなたのシステムは部分的劣化が続いている状態にあります。今、あなたが知らない多くの間違っていたり、壊れているものがあります。」各システムで対処できないノイズについて警告を送信するのではなく、ユーザの不幸を招く可能性がある、より広範な障害パターンに対処する必要があります。

したがって、ユーザが私たちのシステムと対話するたびに提供されるエクスペリエンスの質を通じて、各ユーザの期待を定量化する必要があります。そして、私たちはすべてのユーザがどの程度満足しているかを総計で測定する必要があります。待ち時間やエラー率、離脱率などの要因を記録し、ユーザインタビューなどの直接的なフィードバックを得ることによって、このようなサービスレベルインジケーター(SLI)のようなドラフトから始めることができます。

理想的には、当社の製品マネージャおよび顧客成功チームは、ユーザが最も気にかけているワークフロー、および待ち時間やエラーレートのどの程度のしきい値がサポートコールを引き起こすかを知っているでしょう。これらのガイドラインを機械分類可能なしきい値に変換することにより(例えば、「この対話は300ミリ秒以内に完了し、HTTP 200コードで提供された場合には良い」、「このデータレコードは過去24時間に更新されれば十分新鮮」)、システム全体のリアルタイムおよび過去のパフォーマンスを分析することが可能になります。たとえば、適格なイベントの99.9%が3か月間に成功するという目標を設定します。各期間内の1000イベントに1つのエラー予算です。

 

 

Credit: Emily Griffin (@emilywithcurls)

 

パフォーマンスの目標を設定し、時間の経過とともに予想されるエラー予算を設定することで、小さな自己解決できる一時的な変動を無視し、システムが名目上の制限を大幅に超えた場合にのみアラートを送信するようにシステムを調整できます。数時間以内にエラーの継続的な発生率がエラー予算を超える可能性がある場合に限り、システムは人間のページに表示されます。そして私達は工学的な優先順位を試して、許容の余地があり、さらにスピードアップできるかを確認できます。そして、許容レベルの失敗を超えている場合は、信頼性作業に再度フォーカスすることができます。チームが慢性的にエラー予算が足りず、ユーザが不満を言っている場合、おそらくチームは新機能よりもインフラストラクチャーの修正を優先する必要があります。

SLOが危険にさらされている場合にそれを防御するという書面によるチームのコミットメントは、信頼性に関する作業に対する制度的な支援を提供します。適切なバランスをとるSLOは、サービスが絶えず停止しているため、サポートに電話して契約をキャンセルするのではなく、ユーザがまれなエラーから脱し、後で再試行するようにする要があります。

 

Credit: Emily Griffin (@emilywithcurls)

 

ユーザの期待が変化し、速度と信頼性の間で異なるトレードオフが可能になると、SLOは変化する可能性があります。しかし、たとえどれほど雑であっても、ユーザ主導のSLOに焦点を当てる方が、ユーザの影響との相関関係を欠いた非常に多くのメトリックを使用するよりもはるかに優れています。

2. 可観測性をもってデバッグする

低レベルのアラートを排除したので、システムがSLOに従ってサービスが機能していないとシステムが判断した場合はどうすればよいですか。トラフィックのうち、どのサブセットが発生しているのか、または問題を引き起こしているのかを理解するために、デバッグおよびドリルダウンする機能が必要です。それらをどのように軽減し解決するかについて仮説を立て、それから実験を実行して、物事が正常に戻ったかどうか確かめてください。

デバッグする能力は観察可能性の概念と密接に関係しています。それは私達のシステムが、システムを乱したりコードを修正したりする必要なく内部状態を理解することを可能にする十分な遠隔測定を作り出すことです。私たちのシステムとそのパフォーマンスに関する十分な知識を持って、問題を経験しているユーザのために結果の違いを説明し解決するために仮説をテストしたいと思います。250ミリ秒かかる要求と500ミリ秒かかる要求の違いは何ですか?リクエストのサブセットが時間がかかる原因となるパフォーマンスの問題を特定して解決することで、ギャップを埋めることができますか?

 

 

Credit: Emily Griffin (@emilywithcurls)

 

単にすべてのデータを測定して収集するだけでは不十分です。データとそのコンテキストを新しい方法で調べ、問題を診断するためにそれを使用することができなければなりません。観察可能性が必要なのは、事前に考えたものだけでシステムをデバッグすることはできないからです。複雑なシステムの障害は、固定された原因の有限の集合からではなく、原因の新しい組み合わせから生じることがよくあります。当然の結果として、私たちは小規模のステージング環境ではプロダクション環境の失敗を再現できず、事前に予測することができません。

観察可能性に対する私たちのアプローチに関係なく、要求が私たちの分散システムをどのように流れるかについて十分な情報を持つことが重要です。要求がマイクロサービスを通過する場所はそれぞれ、監視しなければならない潜在的な障害ポイントです。これは、メタデータを含む幅広いイベント分散トレース、メトリック、またはログの形式をとることができます。どのアプローチでも、ツールのサポート、データの粒度、柔軟性、およびコンテキストに関してトレードオフがあります。必要な機能をすべて提供するには、連携して機能する複数のツールが必要になることがよくあります。そして、失敗したユーザーワークフローの特定のインスタンスまで手がかりの痕跡をたどることができない場合、問題は最も熟練した問題解決者でさえも困惑させるでしょう。

テレメトリを十分な柔軟性と忠実度で記録することで、その動作を分析するためにサービスを中断したままにする必要はありません。後で問題を再現してデバッグできることを確信して、できるだけ早くユーザにサービスを回復できます。これにより、不良リージョンの排出や不良展開の取り消しなど、クラス全体の問題を自動的に軽減し、通常の勤務時間内に問題の原因を調査することができます。人間が各障害をリアルタイムで完全にデバッグして解決する必要がない場合、システムの操作性は向上します。

3. コラボレーションと建築スキル

SLOと可観測性のための計測ツールの完全なセットでさえも、必ずしも持続可能なシステムをもたらすわけではありません。人々はシステムをデバッグし実行する必要があります。デバッグする方法を知りながら生まれてくる人は誰もいないので、すべてのエンジニアはそれをある時点で学ばなければなりません。システムと技術が進化するにつれて、誰もが新しい洞察で継続的に更新する必要があります。

トレーニングプログラムを開発し、診断のための共通の出発点についての徹底的な最新の文書を作成し、そして非難のないレトロスペクティブを持つことが重要です。サービスの所有権はわがままやサイロを意味するのではなく、それは時間をかけて専門知識を共有することを意味します。何よりも、チームメンバーとチーム外のメンバーが質問できる心理的安全を感じる雰囲気を育む必要があります。これにより、個人は理解を深めることができ、問題に対処するための新しい視点が生まれます。

チーム間のやり取りには、上流/下流の関係だけでなく、カスタマーサポート、製品開発、SREなどの職務も含まれます。カスタマーサポートエンジニアが直近の誤警報を発したときに怒鳴られた場合、彼らは問題を安全にエスカレートすることができないと感じ、問題の検出と解決に苦しむでしょう。

 

 

Credit: Emily Griffin (@emilywithcurls)

 

誰もが本番で失敗するに至ったプロセスをある程度されされることは、学習プロセスにとって重要です。しかし、プロダクションの所有権へのアプローチの多くは、開発者全員を1日24時間、7日をいつでも電話にかけることについては柔軟性に欠け独善的です。開発者は、ストレスがあり、自分の生活に合わせて調整できないプロセスに参加することに反対します。職務内容が彼らの下にシフトしたり、従わなかった場合に職務が縮小したと見なされることはチームの士気を害します。

本番環境は、特定の型に適合するエンジニアだけでなく、あらゆる種類のエンジニアが所有する必要があります。プロダクションへの関与は、オンコールか、そうでないかの二者択一である必要はありません。本番環境への関与は、ポケットベルのストレスに対処できない人のためのサポートチケットのトリアージや、夜間に家族の責任を持つ人のための営業時間中にのみ電話をかけるなど、さまざまな形を取ります。他の例としては、安息日や夜間のオンコールの時間帯に、勤務時間内に1対1を中断する連絡をしたくないマネージャのために電話をかけていない敬けんなユダヤ人が考えられます。チームが協力して、個人の状況やニーズに基づいて本番環境所有権の負荷を公平に分担することができます。

4. リスク分析

本番環境の卓越性の最後の要素は、システムのパフォーマンスにリスクをもたらす構造上の問題を予測して対処する能力です。私たちはパフォーマンスのボトルネックと潜在的な障害のクラスを危機になる前に特定できます。予防的であるということは、失敗する前に、どのようにしてハード依存関係をソフト依存関係に置き換えるかを知ることを意味します。同様に、クリティカルパスを最適化する前に、私たちのシステムが遅すぎるとユーザが文句を言うのを待つべきではありません。新しいシステム障害に対処するためには、まだエラー予算の一部が必要ですが、システム内の既知のリスクに対処を正当化することになりません。

重要なポイントはそれらのリスクが最も重要であることを識別し、それらを修正するために主張することです。1960年代、アメリカのアポロの月面着陸計画既知の危険性のリストを順に並べ、これらの危険性が累積的にプログラムの安全性パラメータの範囲内に収まるようにしました。現代では、Google SREチームがリスクの調査と優先順位付けを支持しています。彼らは、検出/修復までの時間、その影響の重大度、およびその頻度または可能性の積によって各リスクを評価する定量的リスク分析の枠組みを提案しています。

イベントの頻度を常に制御できるとは限りませんが、応答時間を短縮したり、影響の程度を緩和したり、影響を受けるユーザの数を減らすことができます。たとえば、ユーザに対する悪い変更の影響を減らし、必要に応じて復帰時間を短縮するために、カナリアデプロイまたは機能フラグを選択することがあります。改善が成功したのは、平均的なユーザにとっては数分以内に短縮されたためです。カナリアデプロイ戦略では、デプロイに関連する停止を、月に1回2時間の100%のユーザへの影響(月あたり1ユーザあたり120分)から月に1回の30分の5%のユーザへの影響(1ユーザあたり1.5分)に減らすことができます。

 

 

Credit: Emily Griffin (@emilywithcurls)

 

エラー予算のかなりの部分を費やす可能性がある単一のリスクは、システムが壊滅的に失敗し、エラー予算を大幅に超えてしまう可能性があるため、迅速に対処する必要があります。エラー予算を超えている場合、残りの多数の小さなリスクの原因に後で対処できます。また、エラー予算の割合を列挙した定量分析では、各リスクが消費するため、新しい機能を開発するのではなく、相対的な優先順位付けと存在リスクへの対処について議論することが容易になります。

しかし、個々のリスク状況のリスク分析では、すべてのリスクに共通する大きなテーマを見つけることができないことがよくあります。測定の欠如、可観測性の欠如、およびコラボレーションの欠如(本番環境の卓越性の他の3つの重要な側面)は、停止をより長くし、発見することを困難にすることによって他のすべてのリスクを悪化させる体系的なリスクを表します。

本番環境支援は苦痛である必要はない

本番環境の所有権とDevOpsに対する長期的なアプローチを成功させるには、本番環境の卓越性という形で文化の変化が必要です。明確に定義された信頼性の測定、新しい問題をデバッグする機能、知識の普及を促進する文化、およびリスクを軽減するための積極的なアプローチがあれば、チームはより持続可能です。ツールは信頼できるシステムをサポートするのに役立ちますが、文化と人々は最も重要な投資です。

成熟した可観測性とコラボレーションの実践がなければ、システムは技術的な負債の重さの下で崩壊し、いくら人とお金がマシンのギアに刻まれていても行き詰まることになります。エンジニアリングチームのリーダーシップは、ユーザのニーズとビジネスの健全性を持続的に満たすことができるチーム構造と技術システムの作成に責任を負う必要があります。本番環境の所有権と本番環境の卓越性の構造は現代の開発チームが成功するための助けになります。私たちは、無力を感じている運用チームが自分たちで成功することを期待することはできません。

著者について

Liz Fong-Jones氏は、15年以上の経験を持つ開発者の支持者、労働および倫理のオーガナイザー、およびサイト信頼性エンジニアです。彼女はSREおよびObservabilityコミュニティのHoneycomb.ioの支持者であり、以前はGoogle Cloud Load BalancerからGoogle Flightsまでの製品に取り組んでいるSREでした。

Article Resources/DownloadsUploaded attachments:production-excellence-sustainable-operations-complex-systems-4-1559141127272.jpgproduction-excellence-sustainable-operations-complex-systems-6-1559141126905.jpgproduction-excellence-sustainable-operations-complex-systems-5-1559141126233.jpgproduction-excellence-sustainable-operations-complex-systems-8-1559141127840.jpgproduction-excellence-sustainable-operations-complex-systems-1-1559140625913.jpgproduction-excellence-sustainable-operations-complex-systems-9-1559141128489.jpgproduction-excellence-sustainable-operations-complex-systems-3-1559141127567.jpgproduction-excellence-sustainable-operations-complex-systems-2-1559140837675.jpgproduction-excellence-sustainable-operations-complex-systems-7-1559141128228.jpgArticle Resources/Downloads File Display name

この記事に星をつける

おすすめ度
スタイル

BT