重要な SRE 原則とプラクティス: SRE の人間的側面
成功した運用プロセスとは、目指した信頼性を実現して維持するプロセスです。 そのようなプロセスは、その環境に責任を持つ人をどのように扱うかによって、またマシンをどのように扱うかによって左右されます。 サイト リライアビリティ エンジニアリングでは、その実践にとって非常に重要なさまざまな面で、この真実が認められています。
トイル
まず、"トイル" (労苦) という考えを取り上げます。 SRE では、人間によって行われる仕事のうち、特定の性質を持つものをトイルと呼びます。 労務には、長期的に引き換えられる価値はありません。 それによって、サービスがどのような意味でも進行することはありません。 大部分が手作業の繰り返しになることがしばしばです (自動化されているとしても)。 時間の経過と共にサービスまたはシステムが大きくなると、そのシステムに対する要求の数も比例した割合で増加し、さらに多くの手動作業が必要になります。
たとえば、サービスによって、SRE チームがトイルと見なされる次のような運用負荷を被る場合があります。
- 毎週何かをリセットする。
- 新しいアカウントとディスク領域を手動でプロビジョニングする。
- プロセスの再起動を手動で繰り返す。
このような作業は完了しても、サービスが長期的に改善されることにはなりません。 また、このような作業は何度も繰り返す必要があります。
Note
多くの場所で行われているように、何らかのチケット システムでこのような性質の要求を保存する場合でも、チケットの解決を含む作業は依然としてトイルです。 トイルがきちんと記録されるに過ぎません。
SRE では、労務は嫌われます。 彼らは、可能で適切である場合は、それをなくそうとします。 この目的が、SRE で自動化が導入されるケースの 1 つです。 要求を自動的に処理できる場合、要求の列を処理する仕事からチームを解放し、チームはもっと報われる、影響度のある仕事に取り組むことができます。
トイルに関して "適切" という語が使用されるのは、信頼性に関して使用されるのと似ています。 トイル排除の優先度が他の作業より下になることがありますが、全体としては、サービスからトイルを取り除くことは SRE にとって重要な取り組みの 1 つです。
プロジェクト作業と vs. 事後対応型 "ops" 作業
トイルを排除するため、すなわちシステムの信頼性を向上させるために必要な作業を行うには、SRE の時間を適切に割り当てる必要があります。 すべての時間を、目先の問題への対処、ページへの返信、またはチケット キューの処理のみに費やすことがないようにします。 トイルを排除するコード、チケットが不要になるようにセルフサービス自動化を構築するコード、サービスや人をより効率的にするプロジェクトを構築するコードを記述する時間を取っておく必要があります。 よく引用される数字は (元の Google モデルより)、1 つのチームでせいぜい 50% の作業負荷です。
Note
50% はやや恣意的な数字ですが、実際、多くの人にとって妥当な目標として機能するようです。
SRE の人生には、すべての時間を火消しに投入する瞬間もありますが、それがずっと続くことはありません。 チームの事後対応型 "ops" 作業 (その多くが骨折り) が時間の 50% 以上を占める状況が長く続く場合、衰弱し、信頼性が落ちることになります。 そのような状況では、前に説明した好循環は機能することも作られることもありません。 SRE では同様に、バランスの悪い待機仕事に注意します。それもチームに負の影響を大きく与える可能性があるからです。
SRE の中心的なプラクティスと原則についていくつか見てきました。それでは、始め方について少しご説明します。