Upgrade to Pro — share decks privately, control downloads, hide ads and more …

30分でわかるシステム運用アンチパターン / Operations Anti Patterns in 30 minutes

30分でわかるシステム運用アンチパターン / Operations Anti Patterns in 30 minutes

「システム運用アンチパターン - Forkwell Library #4」でお話しした際の資料となります。
https://forkwell.connpass.com/event/256481/

動画はこちら。
https://youtu.be/hQAeMgXsZWc

Yuichi Tanaka

August 22, 2022
Tweet

More Decks by Yuichi Tanaka

Other Decks in Programming

Transcript

  1. 30分でわかる
    システム運用
    アンチパターン
    Forkwell Library #4
    2022/08/23
    田中 裕一

    View full-size slide

  2. 田中 裕一
    GitHub, シニアソリューションズエンジニア
    オープンソースガイド日本語版
    Martin Fowlerの記事の日本語化
    ソースコードブランチ管理のパターン
    テストにおける非決定性の排除
    Twitter: @yuichielectric
    GitHub: @yuichielectric

    View full-size slide

  3. ● 2022/04、オライリー・ジャパンより刊行
    ● “Operations Anti-Patterns: DevOps
    Solutions” Jeffery D. Smith著 (2020/10)
    ● 運用や開発の一般のエンジニアや
    チームリーダーがDevOpsによる変革を起こ
    すための手助け
    ● 11個のアンチパターンを紹介
    ○ ストーリー
    ○ アンチパターンの説明
    ○ 解決策

    View full-size slide

  4. 本書が書かれたきっかけ
    いろんなイベントで話すようになって気づいたのだけど、ほとんどが
    ユニコーン企業についての話だった。彼らは利益はあまり気にせず、いかに売上を
    増やすかばかり考えている。会社を取り巻く力学が全然違う。
    (中略)
    本書は、Netflixのような巨人と自分の会社を常に比較するのは危険であるという考えが
    発端になっている。インスピレーションを得るには良いかもしれないが、
    それは自分たちの問題を解決するとは限らない。他の人の問題を解決するもの
    でしかないかもしれない。
    https://semaphoreci.com/blog/jeff-smith-on-devops-antipatterns
    から抜粋し日本語訳

    View full-size slide

  5. 1. パターナリスト症候群
    2. 盲目状態での運用
    3. 情報ではなくデータ
    4. 最後の味付けとしての品質
    5. アラート疲れ
    6. 空の道具箱
    7. 業務時間外のデプロイ
    8. せっかくのインシデントを無駄にする
    9. 情報の溜め込み
    10. 命じられた文化
    11. 多すぎる尺度

    View full-size slide

  6. 1. パターナリスト症候群
    2. 盲目状態での運用
    3. 情報ではなくデータ
    4. 最後の味付けとしての品質
    5. アラート疲れ
    6. 空の道具箱
    7. 業務時間外のデプロイ
    8. せっかくのインシデントを無駄にする
    9. 情報の溜め込み
    10. 命じられた文化
    11. 多すぎる尺度

    View full-size slide

  7. パターナリスト症候群

    View full-size slide

  8. パターナリスト症候群
    “ある日、ステファニーが社内システムにデプロイをした。デプロイには
    システム再起動が必要だが、この時間にその社内システムを使っている人は
    いないとわかっていたので、問題ないはずだった。しかし、今回は急ぎの
    作業でそのシステムを使っている人がいた。
    デプロイの結果、その人の作業内容が失われてしまい、その人は作業を
    やり直す羽目になった。
    翌日、その人のマネジャーが憤慨し、再発防止を要求。その結果
    この会社初の変更管理ポリシーが誕生した。”

    View full-size slide

  9. 導入された変更管理ポリシー
    1. 開発者は変更をデプロイするためのチケットを少なくとも3日前に提出。
    3日前までに通知されていない場合は1に戻る。
    2. 利用部門によるスケジュールを確認。もしデプロイ予定の日にその部門での
    作業が予定されている場合は1に戻る。
    3. 運用部門による承認。デプロイの前日までに2まで完了している必要があ
    る。完了していない場合は1に戻る。
    4. デプロイの実行。ただし、その際にログインユーザーがいた場合はデプロイ
    を中止し1に戻る。

    View full-size slide

  10. 何が問題か?
    ・デプロイ頻度が多くても週に1回に制限される
    ・チーム間の余分なコミュニケーションが生じる
    ・利用者の一人でもログインしっぱなしの場合
     デプロイできない
    「システム運用アンチパターン」p.17 図2−1より

    View full-size slide

  11. 達成したいこと:
    システムの安全性を高める
    󰡿な解決策:
    そのタスクを実行・承認できる人を
    少数の人に制限する

    View full-size slide

  12. パターナリスト症候群
    パターナリスト:
    親子関係のように、強い立場にある者が弱い立場の者に対して介入すること
    “パターナリスト症候群では仕事の進め方やタイミングをゲートキーパーと呼
    ばれる、権力を持つ人に委ねます。このような権力の集中は、最初は懸命な
    判断のように見えますがすぐに生産性の低下を招きます。”
    (「システム運用アンチパターン」p. 9より)
    症状:
    ・作業の受け渡し
    ・承認
    ・過度なアクセス制限

    View full-size slide

  13. 自動化で解決
    待ち時間
    ● 変更申請を出してから4日以上待つ
    実行時間
    ● 人手でスケジュールの確認、デプロイ等
    実行頻度
    ● 週に一度の変更が限界
    実行のばらつき
    ● 人為的ミス

    View full-size slide

  14. 自動化の考慮事項
    承認プロセス
    ● 何をチェックするか
    ロギング
    ● 依頼・承認・実行・結果をどこに記録するか
    ● 社内のイシュー管理ツールに集約するのがおすすめ
    通知
    ● 処理が実行されたことをどこで誰に通知するか
    ● 通知先の管理コストをいかに減らすかが大事
    ● 既存のシステム(オンコールシステムとか)があればそれを活用
    エラー処理
    ● どの程度まで自動復旧を行うか
    ● 自動復旧よりもエラーを出して人間に判断してもらうので十分な
    ケースも多い

    View full-size slide

  15. アラート疲れ

    View full-size slide

  16. アラート疲れ
    “レイモンドがオンコール担当していた日の午前4時、データベースの
    CPU使用率が95%になっているというアラートで起こされた。
    調査を開始したが、システムのアクティビティは正常。データベースのログ
    にエラーも出ていない。1時間ほど寝ずに調査を続けても、おかしな所は
    見つからない。そのうちにデータベースのCPU使用率も正常に
    戻っていった。
    しかし、その次の日も同じアラートで夜中に起こされることになる。”

    View full-size slide

  17. 何が悪いのか
    ・オンコールを担当するエンジニアの健康を損なう
    ・アラートが無視されたり、応答が遅れたりするようになる

    View full-size slide

  18. 良いアラート
    ● 行動可能である
    ○ システムメトリクスによるアラートは行動可能でない
    場合が多い
    ○ 受け取った時に取るべき手順(runbook)
    ○ なぜ通知する必要のあるアラートなのか
    ● タイムリーである
    ○ 待てば解消されるかもしれない事象をアラートする
    のはやめる
    ● 適切に優先順位づけされている
    ○ 全てのアラートが誰かを呼び出す必要はない

    View full-size slide

  19. カスタムメトリクス
    ユーザー/ビジネスの観点でシステムが正常に動作しているかどうかを
    知るためのメトリクス
    ● スループット
    ● エラー率
    ● レイテンシ
    開発・運用・プロダクトチームの協力が必要

    View full-size slide

  20. 故障モード影響分析
    エラーが発生する可能性のある箇所を洗い出し、以下の軸を1〜10で
    スコアづけ
    - 深刻度   (1:深刻でない  〜 10:深刻)
    - 発生頻度  (1:ほぼ発生しない〜 10:頻繁に発生する)
    - 検出可能性 (1:検出が容易  〜 10:検出不可能)
    これら3つのスコアを掛け合わせて値が高いものから優先

    View full-size slide

  21. アラートの計測
    ● ノイズ率
    ● オンコール幸福度
    ○ 誰がアラートを受けているか
    ○ どの程度の緊急度か
    ○ どのように通知されているか
    ○ いつ受けているか

    View full-size slide

  22. ● 11あるアンチパターンのうちの2つを
    紹介しました。
    ● ほかのパターンを知りたい方は
    ぜひ本書を手にとっていただけると
    嬉しいです。
    ● シナリオがあるあるだと思うので、
    社内勉強会で使って、改善に向けた仲間を
    集めるのにも使えるかも。
    まとめ

    View full-size slide

  23. https://note.com/yuichielectric/n/n45b907b9dd93

    View full-size slide