忍者ブログ

ひつ(じのひよこが)プログラミングします。
お仕事や趣味で困ったこととか、何度も「あれ?どうだったかしら」と調べたりしたこととか、作ったものとか、こどものこととかを書きます
★前は週末定期更新でしたが今は不定期更新です

2024/11    10« 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  »12

事故管理についてメモ2 トラブル対応をチームでやる?

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

コメント

ただいまコメントを受けつけておりません。

事故管理についてメモ2 トラブル対応をチームでやる?

本番環境におけるトラブル対応が難しい。実際にはトラブル対応そのものはちゃんと動くのだが、しばしば記録がちゃんと残されない。トラブル対応を担当した人はその記録を残すだけの余力がないのである。

Google - Site Reliability Engineering Chapter 14 - Managing Incidents において本番環境におけるトラブル対応について以下の4つの役割からなるチームで行うことを提案している。なるほど、手分けすれば記録もできそうだ。

Incident Command

The incident commander holds the high-level state about the incident. They structure the incident response task force, assigning responsibilities according to need and priority. De facto, the commander holds all positions that they have not delegated. If appropriate, they can remove roadblocks that prevent Ops from working most effectively.

Operational Work

The Ops lead works with the incident commander to respond to the incident by applying operational tools to the task at hand. The operations team should be the only group modifying the system during an incident.

Communication

This person is the public face of the incident response task force. Their duties most definitely include issuing periodic updates to the incident response team and stakeholders (usually via email), and may extend to tasks such as keeping the incident document accurate and up to date.

Planning

The planning role supports Ops by dealing with longer-term issues, such as filing bugs, ordering dinner, arranging handoffs, and tracking how the system has diverged from the norm so it can be reverted once the incident is resolved.

なんとなく日本語で楽に書くと以下の感じになるだろうか?

Incident Command (しれーかん)
トラブル全体を見渡し、関係者に役割を振り分けて担当する。トラブル対応がスムーズにいかないあらゆる理由をやっつける係。また、他の役割が担わない全てのタスクをやっつける
Operational Work (ぜんえい)
実際に本番環境に対して影響を与えるようなアクションを行ってトラブルを実際に解決する担当者
Communication(れんらくたんとー)
トラブル担当チームやステークホルダーと連絡をとり、情報発信を行う。また、関係する文書を最新の状態に保つ
Planning(ぷらんにゃー)
問題の記録や環境が予定とどう違う挙動をしたのかを追跡し、関係各所との調整を行って問題の後始末をする

現時点での私の感覚的には役割がちょっと細分化されすぎている印象を受けた。Incident Command が Communication と Planning を担えば私が今やっているお仕事の範囲であれば十分な気がしたのである。しかし、2つの役割には分けたい。対処を行いながら記録や関係各所への連絡までやる、というのは少々無茶が過ぎる。

しかし、トラブル対応を2人体制で行うための人員を捻出することが果たして可能なのか怪しいのではないか、という見解もある。人が単純に足りていないのもあるとは思うが、それに人を費やした際に得られる成果はせいぜい 1.5 人分ではないのか?という指摘を他の人から頂いたし、自分も少し感じている。人を分けることで得られるメリットは「ステークホルダーとの連絡がスムーズ」「トラブルの記録がきっちり取られやすい」があると考えている。これがのこり 0.5 人分ないしそれ以上のメリットを生み出せると断言できれば良いのだが。


2人体制でやる、となれば「姉妹制度」とか「ロッテ」とか呼びたい。なお、後者はドイツ語である。

PR

コメント

ただいまコメントを受けつけておりません。

ブログ内検索

P R