OpsJAWS Meetup21 システム運用アンチパターンのすすめ

Slide 1

Slide 1 text

OpsJAWS Meetup#21 システム運用アンチパターンのすすめ 2022-06-21 吉井亮 1

Slide 2

Slide 2 text

自己紹介吉井亮 (Yoshii Ryo) 経歴: HWエンジニア → 中小SIer → ERPコンサル → 現職(AWSパートナー) Twitter: @YoshiiRyo1 好きな言葉: no human labor is no human error 2

Slide 3

Slide 3 text

おすすめしたいシステム運用アンチパターン ――エンジニアがDevOpsで解決する組織・自動化・コミュニケーション Jeﬀery D. Smith　著、田中裕一　訳 2022年04月発行 352ページ https://www.oreilly.co.jp/books/9784873119847/ 3

Slide 4

Slide 4 text

本日の内容『システム運用アンチパターン』を紹介・抜粋しながら運用アンチパターンを回避する策を考察します (Opsがメイン) 4

Slide 5

Slide 5 text

Let’s tweet #opsjaws #jawsug を付けながら「あるある」「うちではこうだった」とつぶやいてもらえれば嬉しいです 5

Slide 6

Slide 6 text

『システム運用アンチパターン』対象読者 ● 技術チームの運用担当 ● 技術チームの開発担当 ● これらのチームリーダーや一般エンジニア ● 限られた権限しか持たない人を前提 6

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

ベースとなる考え (CAMS) DevOps 文化自動化メトリクス共有 8

Slide 9

Slide 9 text

ゲートキーパー 9

Slide 10

Slide 10 text

パターナリスト症候群親子関係のように、強い立場にある者が弱い立場に対して介入することを指す例) 運用グループがシステム変更に対して広範なレビュープロセスを実施する ❌ アンチパターン 10

Slide 11

Slide 11 text

パターナリスト症候群が進むと何がおきるか ● 安全装置のはずの承認が障壁になる ● 特定の人(達) だけが実行や承認をする → ゲートキーパー ● ゲートキーパーと仕事するようになる ● 摩擦がおきる ❌ アンチパターン 11

Slide 12

Slide 12 text

自動化によりパターナリスト症候群の解消手動プロセスをテクノロジーで自動化 🙅 承認は人間がするもの 🙅 12

Slide 13

Slide 13 text

承認の目的を把握自動化するが承認の目的は果たす ● 作業を継続するのに適切な状態である ● 作業が発生していることを知らせる ● アクションの衝突がない ● 変更のリスクが許容できる範囲である 13

Slide 14

Slide 14 text

運用の自動化 14

Slide 15

Slide 15 text

自動化による改善 ● 待ち時間 ● 実行時間 ● 実行頻度 ● 実行のばらつき 15

Slide 16

Slide 16 text

自動化する ● 自動化を文化とする ● ツール開発運用をする人員の確保 ● 手動での作業を良しとしない ● 手動作業のコストを計算する ● 自動化タスクに安全性を取り入れる 16

Slide 17

Slide 17 text

自動化に伴うリスクをプロット低い高い高い [低リスク] 自動化 [中リスク] 処理の途中でユーザーに確認を取るタイプの自動化低い [中リスク] 処理の途中でユーザーに確認を取るタイプの自動化 [高リスク] 必要な情報は手動で入力するタイプの自動化間違えた場合の重大さ自信の度合い 17

Slide 18

Slide 18 text

デプロイの自動化 18

Slide 19

Slide 19 text

デプロイを日常的に行う ● 正確な本番前環境 ○ 違いが可能な限り少ない環境 ○ コンテナ ● 頻繁に行うことで恐怖心を減らす ● リスクを減らして恐怖心を減らす 19

Slide 20

Slide 20 text

デプロイ失敗への対応 ● ロールバック可能なデプロイ ○ Blue/Green, Canary, Rolling ● アーティファクトの活用 ● 破壊的変更は複数段階を経て 20

Slide 21

Slide 21 text

組織の文化 21

Slide 22

Slide 22 text

組織の文化 22 メインロビーに飾られているプレートではなく、具体的な形で存在しているべき育て、発展させ、行動で示される

Slide 23

Slide 23 text

ピーター・ドラッカー企業文化は戦略に勝る 23

Slide 24

Slide 24 text

文化とはあるグループの人々をほかのグループから区別する、共有された価値観・習慣・信念の集合体として定義される。 24

Slide 25

Slide 25 text

文化を根付かせるには？ ● 言葉による共有 ● 物語による共有 ● 習慣による共有 ● 文化チーフ (文化的価値観を体現する人) ● 価値観を調べる ● 文化に合った人材を見つける 25

Slide 26

Slide 26 text

開発・運用役割の変化 26

Slide 27

Slide 27 text

責任の変化開発 → 自分たちが書いたコードが本番環境でどのように動くか詳細に理解運用 → プロダクトの挙動を詳細に理解 27

Slide 28

Slide 28 text

AWS Well-Architected の話し 28 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/fully-separated-operating-model.html

Slide 29

Slide 29 text

AWS Well-Architected の話し 29 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/separated-aeo-and-ieo-with-centralized-governance-and-a-service-provider.html

Slide 30

Slide 30 text

ポストモーテム 30

Slide 31

Slide 31 text

インシデントの振り返りをしていますか？ 31 ● 責任のなすりあい ● 自分は無実だと証明することに躍起 ● 情報の壁 ● 行動と人格 ● トリプルチェックの導入 ❌ アンチパターン

Slide 32

Slide 32 text

良いポストモーテム ● 非難のない文化 ● システムの問題、プロセスの問題 ● 24時間以内にポストモーテムを実施 ● 今となっては明白でも同時はあいまい ● インシデントの全容解明が主目的 32

Slide 33

Slide 33 text

アクションアイテムの定義 ● 可視化できていない箇所を可視化 ● システムの可用性を向上させる ● 誰がいつまでに何をするか ○ 日常業務から離れることの理解 33

Slide 34

Slide 34 text

ポストモーテムのドキュメント化 ● インシデントの詳細 ● インシデントサマリー ● インシデントウォークスルー ● ポストモーテムの共有 34

Slide 35

Slide 35 text

アラートに疲れない 35

Slide 36

Slide 36 text

アラート基準 ● Runbook を含める ● 次の行動が可能である ● タイムリー ● 適切な優先順位付け 36

Slide 37

Slide 37 text

オンコールローテーション ● 最初の連絡者(達)を定めたスケジュール ● 1週間で交代 ● アラートの重要度に合わせて通知手段を変える (電話、Slack、メール等) 37

Slide 38

Slide 38 text

オンコールローテーションの配置 ● 4人以上でローテーションを回す ● プライマリ、セカンダリ ● 精神的、肉体的負担への配慮 ● 金銭的補償 ● 代休 ● 在宅対応 38

Slide 39

Slide 39 text

情報のため込み：ブレンドだけが知っている 39

Slide 40

Slide 40 text

情報のため込みを理解する 40 ● 組織構造・インセンティブ・優先順位・価値観の組み合わせによって発生する ● 意図的なためこみ ● 意図しないためこみ

Slide 41

Slide 41 text

意図的なためこみ ● ゲートキーパーになりたい 41

Slide 42

Slide 42 text

意図しないためこみプロジェクトでは機能実装を優先した → ドキュメントは後回しになった → 落ち着いたと思ったら別プロジェクトへ 42

Slide 43

Slide 43 text

ドキュメント化 ● 価値があるものはドキュメント化する ● そうでなければ省略してもよい ● 書くタイミング ○ コード、インフラは陳腐化する ● 抽象化 ○ 要件、目的、他システム影響がある部分 43

Slide 44

Slide 44 text

ナレッジストアの構築 ● ドキュメントを共有する ● 検索しやすくする ○ 階層化、タグ ● 「ただ置く場所」にならないように ● 習慣付け ○ 学習～ドキュメント化～共有 44

Slide 45

Slide 45 text

情報のため込み方 ● ストック ○ ナレッジストア ○ ブロク ● フロー ○ チャットツール ○ SNS 45

Slide 46

Slide 46 text

最後に 46

Slide 47

Slide 47 text

おすすめしたいシステム運用アンチパターン ――エンジニアがDevOpsで解決する組織・自動化・コミュニケーション Jeﬀery D. Smith　著、田中裕一　訳 2022年04月発行 352ページ https://www.oreilly.co.jp/books/9784873119847/ 47

Slide 48

Slide 48 text

48 Thank you for your good ops.