BOOK IT

【要約】システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション|本のまとめ。

次の方を対象にしています!


システム運用アンチパターン」を参考に説明します。


参考: システム運用アンチパターン


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

システム運用アンチパターン 要約|DevOpsを構成するもの。まとめ

DevOpsの定義は次のとおりです。


ソフトウェア開発の考え方をほかの役割に適応するようなソフトウェア開発手法のことです。DevOpsでは、ソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有することを重視しています。従来は開発者中心であった業務を運用チームのメンバーが担い、開発チームのメンバーも同様の業務を行うことで、職能の垣根が低くなります。DevOpsという言葉は開発とIT運用に関連するものとして知られています。しかし、このアプローチはセキュリティ(DevSecOps)、QA、データベース運用、ネットワークなど、ほかのグループにも拡張できます。


DevOpsは4つの柱に支えられています。「文化 culture」「自動化 automation」「メトリクス metrics」「共有 sharing」です。これらを略してCAMSと呼びます。

システム運用アンチパターン 要約|パターナリスト症候群。まとめ

パターナリストとは強い立場にあるものが弱い立場にあるものに対して介入することです。権力のある人に委ねる動きをすると生産性の低下を招きます。パターナリストに注意しながら運用する必要があります。

DevOpsのゴール

  • チーム間のコラボレーション強化
  • 不必要なゲートや作業の受け渡しの削減
  • 開発チームがシステムを所有するために必要なツールと権限の提供
  • 再現性のある予測可能なプロセスの構築
  • プリケーションの本番環境に対する責任の共有



DevOpsではCAMSモデルに沿ってこれらを実現します。またチーム間のやりとりに承認や依頼、権限の誇示が関わると目標達成が難しくなります。プロセスのこのような活動をゲートキーパータスクと呼びます。気をつけないと遅延やチーム間の摩擦を生むことになります。ゲートキーパーはパターナリストの中心的存在です。


承認や確認を増やすのではなく、自動化して承認や確認をなくしていきます。承認が必要となった背景や目的を把握したえで、承認の何が問題なのか、なぜ自動化するのかも含めて話し合うのがよいでしょう。

プロセスを自動化ためのチェック項目

  • 承認プロセス;実行を許可するために必要なチェック項目は何か?
  • ログイン具プロセス;依頼・承認・実行・結果をどこに記録するか?
  • 通知プロセス;処理が実行されたことを自動ツールがどこで人々に通知するか?
  • エラー処理;どの程度まで自動復旧を行うか?


システム運用アンチパターン 要約|盲目状態での運用。まとめ

開発者は自分のコードが本番環境でどう動作しているかを確認できなければなりません。理解できていなければ未知の挙動に悩まされます。システムを理解したうえで、システムが期待通り動いているか確認できなければなりません。エラーがないことが正常とは限らないのです。


またプロダクトを理解することで、システムが期待通り動作しえちるか確認するためのメトリクスを深く理解できます。


次に運用の可視化です。メトリクスとログが主な情報源になります。メトリクスとはシステムリソースのある時点での測定値です。ログは、システムで発生したイベントを記述したシステムのメッセージです。ログにはイベントの詳細が含まれるためメトリクスよりも詳細を把握できます。


動作を確認するために役立つメトリクスは「スループット・エラー率・レイテンシ」です。

  • スループット:一定基幹のシステムを流れる仕事の量
  • エラー数:システムにリクエストされたうち、エラーになった割合
  • レイテンシ:特定のアクションが完了するまでの時間を測定したもの



さらにメトリクスにはゲージとカウンタがあります。ゲージはある特定の瞬間における数値、カウントはそのイベントが発生した回数です。


メトリクスの値がどうなった場合にエスカレーションして調査を行うかを決めます。単純にアラートを出せばよいわけではなく、サービスのパフォーマンスが変化したことを知り、システムが健全かを再評価するきっかけとなるものが必要です。運用に適したキャパシティを見直すきっかけにもなります。


昔から使われる手法として故障分析モード(FMEA)があります。プロセスを調査して失敗またはエラーになる可能性のあるすべての領域を特定します。


エラーが発生する可能性のある箇所を特定し、エラーを3つの軸で1〜10で評価します。

  • 深刻度:エラーが起きるとどれだけひどい状態になるか
  • 発生頻度:エラーがどのぐらいの頻度で発生するか
  • 検出可能性:システムやメトリクスがエラーを検知する前に、ユーザがそのエラーに気づく可能性



この3つの軸をかけ合わせて数値化します。これをリスク優先番号(RPN)といいます。数値によりリクスが高いものの順位がわかります。チームの目標はこのRPNの値を減らすことです。


またシステム障害の際は振り返り(ポストモーテム)をすることで優れたメトリクスを見つけられます。システムとその状況について答えられないような疑問があったのではないか?と話し合うことが大事です。


ログ

注意事項としてログは必ず構造化するべきです。普及しているのはJSONです。機会的に読み取り可能にすることでログ収集システムと連携できます。

ログには次のレベルがあります。

  • DEBUG:プログラムのあらゆる情報を出力
  • INFO:ユーザが開始したアクションやスケジュールされたタスクの実行などのシステム操作
  • WARN:将来絵t機にエラーになる可能性のある状態。パフォーマンス低下などの警告
  • ERROR:すべてのエラー状態
  • FATAL:システムをシャットダウンさせるすべてのエラー状態



適切なレベルでログを出すかはエンジニアの実装次第です。


良いログメッセージの鍵は文脈です。ログを見る人はそのメッセージしか見ないという前提で書かれるべきです。「トランザクション完了」だけではなにか分かりません。メッセージだけで理解できる必要があります。


エラーメッセージをログに出力するときは次の情報を残します。

  • 何のアクションが実行されたか
  • そのアクションの期待される結果は何か
  • そのアクションの実際の結果は何か
  • 取るべき修復手段は何あk
  • エラーによって引き起こされる潜在的な結果は何か


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

システム運用アンチパターン 要約|情報ではなくデータ。まとめ

利用者のことを考えてダッシュボードをつくります。

  • 折れ線グラフ:時系列で変化のばらつきや現在の状態を確認できる
  • 面グラフ(積み上げ折れ線グラフ):折れ線グラフにプラスして、各サーバーごとなど内訳も確認したい場合に使う
  • 棒グラフ:頻度の低いデータや欠損値がある場合に有効なグラフ。頻度が低いデータに折れ線グラフを使うと不正確なグラフになってしまう
  • ゲージ:ある時点の値を表示する


それらに情報を付加していきます。

  • 色による文脈の付与。ひと目で分かるように正常:青、危険:赤、警告:黄色のように色分けする
  • しきい値線による文脈の付与。しきい値を超えたら悪い状態というのが分かるようにしきい値を線で表す
  • 時間比較による文脈の付与。前日の同じ時間帯とくらべてグラフの変化を比較する



ここから利用者を想定して何をチェックするか決めます。WEBサイトのパフォーマンスなら、レスポンスタイムのレイテンシや1秒あたりのリクエスト数が見たいでしょう。
ダッシュボードに置くウィジェットは左から右。上から下に優先度が高い順番に並べます。


ダッシュボードはいつ誰が見てもわかるようにノートウィジェットを作成します。ノートウィジェットはダッシュボードやウィジェットについて詳しく説明を書いたものです。

システム運用アンチパターン 要約|最後の意味づけとしての品質。まとめ

本番でバグを出さない方法はありません。リリースされてはじめて見つかるバグをなくすことはできません。それを認識します。対処としてはバグを発生しくに状況をつくったり、一度出したバグを再発させないことです。

テストピラミッド

テストスイート(テストの目的や条件が似ている複数のテストケースを一括りにしたもの)の多くはテストピラミッドという考え方を中心にしています。


テストピラミッドはテストをどのようにグループ化するかを示すメタファであり、テストの種類ごとに存在すべきテストの数を示すガイドラインでもあります。テストのほとんどはユニットテストであり、その次に多いのが統合テスト、最も少ないのがエンドツーエンドテストです。


テストピラミッドは上から次の順になっています。

  • エンドツーエンドテスト(ピラミッドの上層):ユーザ視点でのテスト。UIをテストする場合もあることからUIテストとも呼ばれる
  • 統合テスト(ピラミッドの中層):複数ユニットをまとめてテストするもので、ユニットテストよりも堅牢。
  • ユニットテスト(ピラミッドの最下層):最も数が多く、高速で、特定の昨日やユニットをテストする


ユニットテストは、ソフトウェアの個々のユニットやコンポーネントをテストします。ユニットテストは開発者が書くべきです。なえなら開発者がユニット開発している間や続くテストの間に定期的にユニットテストを実行する必要があるからです。


TDDというテスト駆動型開発があります。開発者がコードの要件をテストケースに変換する手法です。


ユニットテストの難しいところは、どういったテストケースを書くかということです。すべてをテストしてしまうと望む結果を得ることが出来ません。テストが多いほどリファクタリングが難しくなります。パブリックなコードパスとプライベートなコードパスを特定することが大事です。パブリックなコードパスに対してユニットテストを行うことで、プライベートなコードパスを変更する際に内部テストのリファクタリングに多大な時間を費やす必要がなくなります。


統合テストはシステム間のやりとりや、ほかのシステムへのアプリケーションのレスポンス処理をテストします。ユニットテストではDBや他のシステムをモックにすることはありますが、結合テストでは実際に接続します。また結合テストは本番環境のインスタンスに対して実行してはいけません。


コントラクトテストは最近見かけるテスト形態です。サービスに対して実行される個別のテストセットで入出力が期待通り動作していることを確認しますものです。依存する外部サービスの挙動変更を検知し、モックやスタブに反映します。外部サービスのレスポンスが変わったことに気づかずリリースしてしまうと障害となりますので、コントラクトテストなどを使って予防しましょう。


最後はエンドツーエンドテストです。UIテストとも呼ばれます。ブラウザやクライアントサイドのアプリケーションを起動し、エンドユーザと同じ方法でアクセスしテストします。


またエンドツーエンドテストは最も不安定で壊れやすいです¥。UIを少し変更すると自動テストを破壊してしまいます。そのため「エンドツーエンドテストの数を制限する(アプリケーションのクリティカルなパスのみをテストする)」「エンドツーエンドテストでは機能についてのテストに限定しパフォーマンスはテストしないようにする」「エンドツーエンドテストは可能な限り分離する(同一マシンで複数のテストを実行しない)」をしてください。


虚栄メトリクスに気をつけてください。品質を表す何かしらの指標が欲しくなるものです。たとえばテストのカバレッジ率(網羅率)は必ずしもテストの品質を表すものではありません。カバレッジが100%だからと言って堅牢とはかぎらないのです。

継続的デプロイと継続的デリバリ

継続的デプロイとはメインブランチへのコミットが常に本番環境へ反映されるデプロイ方法です。常に最新化されるため、人は介入しません。一方で継続的デリバリはアプリケーションを常にデプロイ可能状態にすることを目的としています。メインブランチは常にリリースできる状態ということです。


自動でデプロイされるのが継続的デプロイであり、デプロイできる状態だがデプロイは手動で行うのが継続的デリバリです。どちらも他のチームの影響を受けずにリリースが可能なことが特徴です。


常にリリースできる状態を担保するためにデプロイパイプラインが必要です。ユニットテストやアプリケーションコードの検証などが構造化され、自動で実行されるステップのことです。パイプラインのステップは次のようなものです。

  • コードをチェックアウト
  • リンターやシンタックスチェッカーなどで静的な解析
  • ユニットテストの実行
  • 結合テストの実行
  • エンドツーエンドテストを実行
  • ソフトウェアをデプロイ可能なアーティファクトにパッケージ
    • アーティファクトとはWARファイルやZIPファイルなどデプロイ可能なファイルにすること



リリースはするがすぐにユーザが使うわけではない場合は「機能フラグ」を使って機能を隠すこともできます。リリースはされるが「機能OFF」で実行されない状態を作れます。DBから値を取得して制御する方法もあります。


またテストされる環境のインフラの管理も必要です。

  • 継続的インテグレーションサーバ
  • パイプラインから生成されたアーティファクトのストレージ
  • テストサーバ
  • テスト対象のソースコード
  • 実行されるテストスイート
  • テストスイートが必要とするすべてのライブラリと依存関係


またDevSecOpsという新しい分野が生まれつつあります。ここまでのライフサイクルで「セキュリティ」がでてきてません。セキュリティチームをDevOpsのサイクルに組み込むことで品質とセキュリティが担保されます。

\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

システム運用アンチパターン 要約|アラート疲れ。まとめ

アラートを設定しすぎたせいで、アラートがなっても無視されてしまい、いつの間にかアラートが正常だと見られてしまうことがあります。これをアラート疲れと呼びます。チームを燃え尽き症候群に導く可能性があります。


オンコールローテーションを組むと良いでしょう。オンコールローテーションは特定の個人を一定期間、システムまたはプロセスの最初の連絡先としてしています。担当者が一次対応や連絡を行います。典型的なローテーションは1習慣単位であり、各メンバーが週替りでオンコール対応を行います。これにより担当週ではなければアラートを見なくて済みます。ONとOFFがしっかりできるのです。


オンコールローテーションは次のことを決めます。

  • プライマリオンコール担当
  • セカンダリオンコール担当
  • マネージャー


そして、アラートから対応の時間を決めます。

  • 確認までの時間
  • 開始までの時間(解決に向けて作業を開始する時間)
  • 解決までの時間



またオンコールは負荷になります。深夜や休日に対応することもあるでしょう。そのため対応者には補償を行います。多いのは金銭の支払いか、休暇です。


アラート疲れをなくすために適切なアラート設定にすることも大切です。しきい値や頻度など確認しながらチューニングしましょう。

システム運用アンチパターン 要約|空の道具箱。まとめ

プロダクトに集中することも必要ですが、プロダクトで使うツールに注目するのも重要です。適切なツールを使うことで効率化できます。それにより時間やエンジニアの節約にもなります。


それをせずにツールを使わず人力でなんとかしようとするのを投資の欠如「空の道具箱」と呼んでいます。


運用の自動化は運用をサポートするツールを開発し、システムやプロダクトの構築・保守・サポートに必要な活動を自動化します。自動化すれば時間もできよりプロダクトに集中できるのですが、なぜか自動化の優先順位は下がってしまいます。もっと自動化を優先すべきです。

システム運用アンチパターン 要約|業務時間外のデプロイ。まとめ

業務時間外のデプロイは組織を守るために正当化されがちですがアンチパターンです。このパターンを採用してもただの対症療法にしかなりません。デプロイをもっと簡単にすることで負荷を減らせます。


新しいコードをデプロイすることと、新しい機能をデプロイすることは同じではありません。この2つは切り離すことができます。新しいコードはリリースするが機能フラグをOFFにして、動作點せ無い状態でリリースが可能です。これにより、DBやコードなど必要な変更を順次行ったあとに、機能フラグをONにし、機能を開放できます。


またデプロイを日常的に行えるようにするために本番前環境を確保します。デプロイ前に本番以外の環境で動くことを確認します。本番前環境は、本番環境と極力同じにします。違いとしてはパフォーマンスに特化したチューニングを施さない程度にするべきです。環境が近いほどデプロイプロセスを信頼できます。しかし残念ながら本番前環境(ステージング環境)はコスト削減の対象になりがちです。フォーカスすべきはアーキテクチャ的に同じ環境を実現することです。サーバの規模や数が異なっていても、サービスを提供するパターンは本番前の環境で再現されるべきです。


またユーザの操作や行動を事前にチェックするために合成トランザクションを使用します。合成トランザクションはユーザが通常行うであろう活動をシュミレートするためのスクリプトやツールのことです。事前にユーザの動作が問題なく行えることの確認ができます。しかしユーザは想定外の行動をするものです。合成トランザクションがすべてを解決してくれるわけではありません。


デプロイに恐怖心がある場合は頻度を見直しましょう。四半期に1度のデプロイでは緊張するのも当たり前です。週に1回デプロイするのであれば、デプロイに慣れていき恐怖心も薄れていきます。


機能フラグでのON・OFFを選択できない場合のロールバックは2種類あります。

  • フリートロールバック(ブルーグリーンデプロイ)。新旧で別の場所にデプロイしておき、ロードバランサーの切り替えにより、新しい方に切り替える方法です。ロールバックのときは古い方に切り替えます。
  • ローリングデプロイ。複数の稼働中サーバーに対して一定数づつ新しいアプリケーションをデプロイ、リリースしていく方法です。


データベースの変更

カラムを変更するときは、カラム自体を変更するのではなく、新しいカラムを作りましょう。一度カラムを変更してしまうとロールバックが難しくなります。そのため新しいカラムを作り、そこにデータを少しずつ移行していく方が安全です。変更が終わり、問題ない状態が確認できたら元のカラムを削除すれば良いのです。


次にデータベースのバージョンです。データベースのバージョンも変わっていくため、アップデートが必要になります。そのときに検証するためには現在のバージョンで実行されたSQLを把握する必要があります。そのSQLが新しいバージョンで同じ結果になれば問題がありません。またFlywayのようなツールを使うとデータベースのバージョン管理が可能です。

\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

システム運用アンチパターン 要約|せっかくのインシデントを無駄にする。まとめ

予期せぬ、または計画外の出来事がおきてシステムに悪影響を及ぼすことをインシデントと呼びます。インシデントが発生したときはチームで学習する機会を増やせます。


インシデントが起きた時に情報をまとめたものをアフターアクションレポート、インシデントレポート、レトロスペクティブなどと言われますが、ここではポストモーテムと呼びことにします。


ポストモーテムはインシデントが至るまでの出来事を評価するプロセスです。関係者全員で話し合いながらまとめていきます。やってはいけないことはミスした犯人探しや罰したり、恥をかかせることです。問題が起こさせたのは人ではなく、システムです。システムを改善することでインシデントを防ぎましょう。


また24時間ルールというのがあります。インシデントが発生した24時間以内にポストモーテムを行うというシンプルなものです。


ポストモーテムのルール

  • 人を直接批判してはならない。行動や振る舞いに焦点を当てる
  • 誰もが、その時点で得られた情報の中で、最善の仕事をしたと考える
  • 今となっては明白な事実であっても、その場ではあいまいだった可能性があることを認識する
  • 人ではなくシステムを責める
  • 最終的な目標は、インシデントに関与したすべての要素を理解することである


次のようなことを話し合います

  • タイムライン
    • どのようなアクションが行われたか
    • 誰が行ったか
    • いつ行ったか
  • イベントに文脈を追加
    • なぜそれが正しい行動だと思ったか
    • システムで何か起こっているか、どのように解釈したか
    • ほかの行動を検討したか、検討した場合はなぜ排除したか
    • 誰か他の人がそのアクションを取る場合、あなたがその時に持っていた知識をどのように得るのか
  • 今後のアクションアイテム
    • 実行する必要のある作業の詳細な説明
    • チームが考える、その作業にかかる時間のおおよその見積もり
    • 作業の優先順位を決める決定権のある人


またドキュメント化するときは「インシデントの継続期間」「解消した時間」「影響範囲」を記載します。

システム運用アンチパターン 要約|情報のためこみ:ブレントだけが知っている。まとめ

情報がキーパーソンだけに集中してしまうことがあります。キーパーソンの価値は高まりますが、負担も大きくなります。また不在の場合に、作業が止まることもあるため、情報共有が必要です。

  • どのように情報が溜め込まれているかを理解しましょう
  • 意図せず情報を溜めてしまっている人を認識しましょう
  • ドキュメントを最大限残しましょう
    • ドキュメントを残すも更新されなければ意味がありません。ドキュメントはゴールではなく、ゴールは情報共有です。ドキュメントの価値はそれを作成する機会費用を上回るものでなければなりません
  • 何か重要な情報があるとアクセス制限をするものです。ドキュメントが見れないことで情報が共有されないことがあります。本当にアクセス制限をする必要があるか考えましょう
  • 情報の検索を容易するためにドキュメントの保管場所の構造を作りましょう


システム運用アンチパターン 要約|命じられた文化。まとめ

文化とは、あるグループの人々をのかのグループから区別する、共有された価値観、習慣、深淵の集合体として定義されます。チーム・社会・国などあらゆる種類の文化を含みます。


文化的価値とは、組織を運営し行動する上で必要不可欠であると組織が考えている原則や基準のことです。文化的習慣は、組織内で行われる特定の習慣や行動です。たとえば新入社員が入社したときに自己紹介のメールを全社員に送るなど。


この文化を変えるには、自分たちは文化を変えることができるという信念を持つことが大事です。そのために言葉やメッセージを使い共有していきましょう。

システム運用アンチパターン 要約|多すぎる尺度。まとめ

組織は目標に向かって人を動かす力があり、そのためには優先順位が必要です。しかし多くのチームは全体的な目標ではなく、特定の部分に集中してしまう傾向があります。その特定の部分が組織全体よりも優先されてしまうのです。全体の目標からズレているにも関わらず、その行動が評価されてしまうこともあります。これが多すぎる尺度というアンチパターンです。


一般的に目標には改装があります。上位の目標によって下位の目標が決まります。組織の目標を理解し、自分の仕事をその目標に結びつけることで、そういった感覚をなくせます。


組織の目標はハイレベルで戦略的なものとなります。「加入者数前年比20%アップ」など。そこから部門の目標に落とし込みます。マネジメントチームがエンジニアリングの文脈を考慮して作成したもので、あなたの日常業務に近いものになるでしょう。部門目標をチームや個人目標に結びつけるのが容易になります。チームの目標では、個々のチームが何に取り組むかに焦点を当てます。チームの目標は部門の目標に紐づく必要があります。

優先度、緊急度、重要度

多くの人が重要度と優先度を混合します。優先事項は、他の行動よりも優先されます。しかし、優先事項が他の行動よりも優先されるのであれば、複数の優先事項が存在しないことになります。1人の優先事項は1つまでです。それとは別にタスクには緊急度と重要度とう特性があります。


緊急度はどれだけ早く仕事をしなればならなかということです。重要度はその仕事の深刻さや価値に関係します。

  • 緊急度が高く、重要度も高ければ、すぐに行動する
  • 緊急度が低く、重要度が高ければ、タスクを先送りするが、いつやるかは決める
  • 緊急度が高く、重要度が低ければ、タスクを他人に任せる
  • 緊急度が低く、重要度も低ければ、そのタスクは断る


チームが保留中や仕事の進行中の仕事を把握できるように仕事を整理する必要があります。予定外の作業は混乱を招くため、特定、追跡し、可能な限り減らしましょう。

参考: システム運用アンチパターン


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

  • この記事を書いた人

おやすみドリー

本の要約をする人 | 年間100冊は本を読む | Audible(オーディオブック)、kindle(電子書籍)など読書方法を紹介 | 良い本をたくさんの人に届けたい | ビジネス書・マーケティング・自己啓発・小説を幅広くインプット | ビジネス関連・忘れない読書方法・文章の書き方なども発信中

-BOOK, IT