HumanOpsの概念は、コンピューターシステムの監視に豊富な経験を蓄積し、それに応じてチームが常に準備が整っている結果として、 サーバー密度で生まれました。 会社の初期の頃、私は長い間連絡を取り合っていました。 しかし、チームが成長するにつれて、負荷を分散し、従業員が現在の仕事から離れたり、夜間を含む学校の時間外に電話をかけたりする場合の悪影響を減らすことを目的としたプロセスとポリシーを実装しました。
人々を目覚めさせるように設計された製品を作成して配布する過程で、私たちは顧客が常に準備ができていることに関連する問題に似ていることに気づきました。 顧客とのコミュニケーションにより、このような問題は業界に典型的なものであると確信しました。そのため、使用するアプローチを批判的に検討し、他の市場参加者が使用するベストプラクティスを調査することにしました。 その結果、これにより、HumanOpsと呼ばれる多くの原則の開発と議論のためのコミュニティが作成されました。
DevOpsプラクティス、展開の加速、新しいツールの導入、開発チームと運用チームの団結と同様に、HumanOpsがシステムを構築し、それらと連携するためのより「人道的な」アプローチの採用を支援することを願っています。
カットの下に、HumanOpsの12の原則と、サーバー密度を例として使用したその作業の説明があります。
1.人々はシステムを作成し、問題を解決します
HumanOpsは、システムを作成、使用、および保守する人々に焦点を当てています。 一部の人にとっては、これは明白に思えるかもしれませんが、システムを人なしでは機能できないことを認識せずに、サーバー、サービス、およびAPIのみについて考え始めるのは簡単すぎるため、この考えを最初の原則として定式化することは依然として非常に重要です。
実際には、これは、システムを設計するとき、最初から、何らかの形でシステムとやり取りする人々を考慮することを意味します。
考慮事項：
- システムのどの部分を自動化できますか？ システムが問題自体を解決できない場合にのみ、人間の知性の力に頼って、日常の日常業務への人々の参加を避けるようにする必要があります。
- 人に警告するためにどのアラームを設定する必要がありますか？ どの時点で人間の介入が必要ですか？ これは重要ですか？ ソリューションを標準労働時間に延期できますか？
- 人間の介入が発生した後、チームと経営陣はどのようにこれを認識しますか？ 時間外アラートのジャーナルを保持し、傾向を分析していますか？
2.人々は疲れてストレスを感じ、幸せで不幸です
これから、プロセスの改善を研究し始めなければなりません。 コンピューターを使用すると、時間に関係なく同じように動作することが合理的に期待されます。 もちろん、これはコンピューターシステムの重要な利点の1つです。疲れることなく、割り当てられたタスクを確実に実行できます。
ただし、多くの人が誤って同じロジックを人々に適用しようとします。 異なる状況の人々は異なる行動をすることを考慮することが重要です。 感情、ストレス、疲労はシステムの動作の予測可能性を低下させるため、設計時にはこれらの要因を考慮する必要があります。
例として、人的要因を考えます。 コンピューターは間違いを犯しません。 疲労のために間違ったボタンを押すことはありません。 人々はこれを行うことができ、適切な準備が行われず、対応する保護がシステムに組み込まれていない場合、おそらくどこかで誤解されます。 人的要因はシステムの不可欠な部分であり、非常によく理解されている必要があります。 この現象は、それ自体が問題ではなく症状とみなされるべきであり、その症状は、人が間違った決定をした状況のより慎重な研究を促すべきです。
状況を改善する1つの方法は、トレーニングを使用することです。 問題が現実に発生した瞬間にトレーニングと同じように認識されるように、トレーニングはできるだけ現実に近いものでなければなりません。 従業員は何をすべきかを知っているため、これによりストレスが軽減されます。 ストレスは、システムが機能していないという認識と相まって、不安から生じます。そのため、心の不測の事態の影響を軽減するために、できる限りのことをする必要があります。 さまざまな障害シナリオをシミュレートするために、 戦争ゲームを実施しています。 したがって、解決した状況のすべての従業員は、何をする必要があるかを知っています。
3.システムにはまだ感情はありませんが、SLAはあります
サービスレベル契約（SLA）は、特定のサービスまたはAPIに期待できるものを決定するための実証済みの方法です。 SLAサービスが一貫しているかどうか、そうでない場合はどうすればよいかを簡単に判断できるはずです。
4.時々切断する必要がある
原則番号2と同様に、数か月から数年の間ノンストップで動作できるコンピューターとは対照的に、人々は休息が必要です。 緊急事態に対応し、複雑なシステムに対処すると、人々はすぐに疲れるので、休息と回復の時間はプロセスの不可欠な部分である必要があります。 集中力を維持できるのは1.5〜2時間だけで、その後は休憩が必要になります。 そうしないと、パフォーマンスが低下し始めます。
サーバー密度では、 rotation rotationを使用してこの問題を解決します。 プライマリおよびセカンダリ（プライマリ/セカンダリ）の役割は順番にチームメンバーに渡され、役割に応じて反応時間を決定するドキュメントがあります。 これにより、コンピューターから離れることができないという感覚が軽減されます。 たとえば、セーフティネット（セカンダリ）の専門家は即座に対応する必要がないため、コンピュータの近くに常にいる必要はありません。
さらに、営業時間外の仕事の後の休息時間は自動的に割り当てられます。 従業員はそれをオプトアウトすることができますが、会社はそうすることを決して求めません。 したがって、従業員は回復するのに十分な時間を持っていると確信しており、従業員が強制的にそれを放棄するために押すことはありません。 例えば、これは休息の自動提供によって達成されます-従業員はそれを得るために何もする必要はありません。
5.人間のオペレーターの幸福は、システムの信頼性に影響します
学校の時間外の出来事に対応した後は、良好な人間関係以外で従業員に休憩を与えているように思えるかもしれません。 ただし、ここにはビジネスロジックがあります。過労者は間違いを犯し、オペレータの疲労によって悪化または誘発された重大な事故の多くの例を知っています。
決して使用したくない保険と同様に、このアプローチの直接的な利益を計算することは困難です。 人的エラーの可能性を減らすポイントは、何か悪いことを避けることです。 測定することは困難ですが、間違いなく、オペレーターの幸福を追求する鉄の論理があります。この場合、オペレーターはより良い決定を下すからです。
6.気になる疲労==人間の疲労
あまりにも多くのアラームを受信すると、アラート疲労が発生します。 これらの信号は非常に多いため、オペレータは重要な何かを見逃す危険性があるため、それらを無視し始めます。 この現象は警告システムの有効性を著しく低下させます。警告システムはまれに機能し、本当に深刻な事態が発生したことを人々に知らせます。
この問題を解決するには、監視システムを監査し、生成されたアラームにアクションが必要かどうか、およびこれらのアクションが実際に実行されているかどうかを確認する必要があります。
7.可能な限り自動化し、最後の手段としてのみ人々を引き付ける
この原則は、システムがそれ自体を修復できない場合にのみアラームを人に送信する必要があるため、前の原則と関連しています。 サーバーを再起動したり、別の簡単なアクションを実行するために人を起こす必要はありません。 何かを自動化できる場合は、そうすることをお勧めします。 人々は、困難な状況を評価し、非標準的なアクションを実行するためだけに関与する必要があります。
残念ながら、システムを商用運用した後、自動化にはかなり問題があります。 これは、KubernetesやクラウドAPIなどの最新のテクノロジーを使用すると、ほとんどすべての障害が発生した場合に自動回復を構成できるためですが、新しいテクノロジーを古いシステムに適合させるには多大な労力が必要です。 もちろん、冗長性の使用と新しい何かの導入の両方にお金がかかりますが、これらの費用は、人の時間を節約し、システムの全体的な信頼性を高めることで報われます。
インフラストラクチャを構築するための正しいアプローチは、商業環境では何も手動で行うべきではないということです。 すべてをテンプレート化し、スクリプト形式でフレーム化し、自動的に実行する必要があります。
古いインフラストラクチャをアップグレードするときは、バランスを維持する必要があります。たとえば、システムの主要コンポーネントのコンテナ化は実用的ではない可能性があるためです。 ただし、同様の目標を達成する方法があります。たとえば、自分の機器でホストされているデータベースをAWS RDSなどの管理されたサービスに転送するなどです。
8.すべてを文書化し、全員に教える
実際には、ドキュメントを書くことを好む人はいませんが、チームが成長し、システムがより複雑になるにつれて、これはすぐに必要になります。 システムの内部メカニズムをあまり理解していない人が使用できる十分な量のドキュメントが必要です。 ドキュメントを使用して問題を解決するには、 チェックリストとプレイブックを使用できます。
トレーニングも同様に重要です。 特に、ドキュメントの欠陥を特定するのに役立ちます。 また、インシデントレスポンダーが関与する現実的なシミュレーションを行い、システムの仕組みを説明することも非常に重要です。
すべての会社の従業員がドキュメントを検索して簡単にアクセスできるようにするために、 Google Density ではGoogle Driveを使用しています 。 ただし、配置には他の多くのオプションがあります。
9.誰かを恥じたり非難したりする必要はありません
問題の原因を検索する場合、従業員はほとんどの場合、間違いを犯した、考えられるすべてのシナリオを計画しなかった、間違った仮定をした、または質の悪いコードを書いた人を見つけます。 これは正常なことであり、人々はそれを恥じるべきではありません。なぜなら、次回、事件の調査に協力したいとは思わないからです。
完璧な人はいません。 私たち一人一人は、少なくとも一度は生産で何かを壊しました。 ここで重要なのは、特定の人を責めるのではなく、そのような問題に対してシステムをより良く、より抵抗力のあるものにすることができることです。 システムが意識的に壊れたということはほとんどないので、人々は自分のやったことに気付いた直後に自分の間違いを認識するのに問題がないはずです。 これは迅速な対応のために重要です。 失敗は学習してチームを改善する機会と見なされるべきです。
これは、失敗の原因の非責任分析を使用することで達成できます。その間、インシデントの詳細と主な原因は明確になりますが、ミスを犯した人は呼び出されません。
10.人々の問題はシステムの問題です
人の問題とシステムの問題を別々に考える傾向があります。 サーバーのパフォーマンスとフォールトトレランスを向上させるための追加コストを正当化する方が、スタッフに関連する問題よりもはるかに簡単です。 上記のすべての原則は、人々に関係する問題も同様に重要であり、考慮と予算に適切な時間を割く必要があることを強調することを目的としています。
サーバー密度では、開発サイクルを計画する際に、クラス外での参加を必要とする不測の事態の数を減らす可能性に基づいてタスクに優先順位を付けることがよくあります。 障害の原因の分析中に特定された問題の修正の実装は、状況に対応する過程で人々がベッドから持ち上げられなければならなかった場合、または問題に少なくともそのような可能性がある場合、より高い優先順位を受け取ります。
11.人間の健康はビジネスの健康に影響します
人々の健康と幸福は、問題を解決する一般的な原因に貢献する能力やシステムの問題が利益の減少と評判の低下につながるなど、仕事に影響を与えるため、人々の健康はビジネスの健康に直接影響を与えます。 新しい従業員を見つけるプロセスには多くの時間と労力がかかるため、人々の世話をすることはビジネスにとって有益です。
12.人々はシステムよりも重要です
人々とシステムが互いに影響し、ビジネス全体に与える影響という点で、同じレベルの人とシステムを考慮することは間違いなく重要であるという事実にもかかわらず、人は依然としてより重要です。 結局のところ、ビジネスは何のためですか？ 他の人に商品やサービスを販売するために！ そして、なぜ人々は生計のためではないのに特定の仕事をするのですか？
チームの労働条件の改善は、正当化するのに十分簡単です。 最高の専門家を採用し、維持できるようにするには、作業プロセスを十分に確立する必要があります。 人々が絶えずベッドから持ち上げられ、間違いを恥ずかしくせず、問題を直さないと、これは彼らの状態に悪影響を及ぼします。 長時間にわたって経験するストレスは、高血圧、心臓病、肥満、糖尿病を引き起こす可能性があります。 したがって、多くの組織は、スタッフの幸福に十分な注意を払っていないため、従業員の健康を、時には非常に深刻に損なう可能性があります。
サーバー密度では、これはビジネスの成功にとって受け入れがたい価格であると考えています。
参照：
- オリジナル： Server DensityでHumanOpsを実行する方法 。