トラブル対応中にエンジニアリーダーとして考えていること - Mitsuyuki.Shiiba
を言葉にしてみようと思った。僕のいる場所での話。ステークホルダーに対する窓口としてプロデューサーがいて、僕が開発チームのリーダーをしてるようなとき。 ## 状況を把握する システムトラブルが発生すると場が混乱してることが多い。色んな情報が混ざるし、色んな人から問い合わせが来たりするし、窓口になってくれているプロデューサーからの説明も省略されていることが多い。このときに一番避けたいのは、ミスコミュニケーションによって本当の問題を見失って無駄な作業をしてしまうこと。 なので、まずは落ち着いて状況を正確に把握する。ちょっとでもはやく解決したいから、その断片的な情報を元に調査に入りたい気持ちになるけど、ぐっとこらえて全体像を把握する。 コミュニケーションで特に気をつけるのは、相手や自分の中にある思い込み。思い込みがあると喋るときには（当然分かってることだよね）と言葉を省略してしまうし、聞くときには
KubernetesのLiveness ProbeとReadiness Probeの使い分けを考えたけど結局思いつかなかったや - Mitsuyuki.Shiiba
Liveness ProbeとReadiness Probe KubernetesにはLiveness ProbeとReadiness Probeってのがある。これの使い分けについて考えてたら混乱したのでメモ。 kubernetes.io Liveness Probeは「コンテナが生きてるかどうか」 Readiness Probeは「コンテナがリクエストを受け付けるかどうか」 を示すらしい。 Liveness ProbeがNGのときは、コンテナが再起動される。 Readiness ProbeがNGのコンテナを持ったPodには、リクエストが送られてこない。 うん。ここまでは理解できる。 んだけど、なんでReadiness Probeだけじゃだめなの？ と思ったので考えてみた。Readiness Probeだけでまかなえるんじゃないの？って。ReadinessがOKの場合って、アプリが生きてる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
