2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

読書感想文『運用設計の教科書』監視運用編(p240〜p252)

2
Posted at

書籍情報

書籍名: 運用設計の教科書【改訂新版】 〜現場でもっと困らないITサービスマネジメントの実践ノウハウ〜
著者: 近藤 誠司

著者について

株式会社K-model代表。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。運用設計・運用改善コンサルティングを専門とする。趣味は小説を書くことで、第47回埼玉文学賞にて正賞を受賞。

著者の他の著作

著者リンク


学習メモ

(本書学習メモより:監視運用の設計範囲と対応フロー図のページ。監視オペレーターから運用担当者・保守対応・情報システム室へのエスカレーションパスと、各ロールの役割が整理されていた。)


学んだこと

1. 監視運用の概要(p240)

システムはハードウェアからソフトウェアまで様々なコンポーネントが絡み合って日々のサービスを提供する。バグ・不具合・経年劣化・作業ミスなどによって問題が発生し、不正なデータ入力によるアプリケーションエラーも起きる。

監視運用設計を行うためには、まず基本的な監視システムの仕組みや考え方を理解しておく必要があります。(p.240より)


2. HTTP監視(URL応答)(p242)

HTTP監視で行うことは、応答コードの確認、記載されている文字列の確認、Webページ応答時間の監視。(p.242より)

システムが外部から正常に到達できるかどうかを定期的に確認することで、サービス停止を早期に検知できる。


3. 画面遷移監視(シナリオ監視)(p243)

Webページの認証機能など、利用者が実際に使う機能まで監視したい場合に行う。(p.243より)

監視用アカウントでのログイン確認や、問い合わせフォームからメールが正しく送信できるかの確認など、利用者の実際の操作フローを模倣してシステムの動作を検証する。


4. 監視対応フローを決める(p245)

監視運用では、まず問題を検知したときの対応フローをあらかじめ決めておくことが重要である。

監視は各役割が調査と切り分けを行いながら、解決できない場合は情報をエスカレーションしていきます。(p.245より)

  1. 監視オペレーターが検知・一次対応
  2. 解決できない場合は運用担当者へエスカレーション
  3. 運用担当者でも復旧できない場合は保守対応のサポートを受けて復旧
  4. サービスに影響する重大障害の場合は情報システム室へ連絡

5. アラート検知テストと検知後の情報連携テスト(p252)

監視に関するテストは「アラート検知テスト」と「検知後の情報連携テスト」の2種類に分けて実施する。

アラート検知テストはテスト項目はかなりの量があります。そのため、検知後の情報連携テストと完全に分けて実施することがほとんどです。(p.252より)

検知後の情報連携テストでは、エスカレーションフローが正しく機能するかを確認する。実際のアラートをトリガーとしたい場合は、サービスへの影響が少ないサーバーを停止させるなどして擬似的に障害を発生させてテストを行う。


感想

現職はデスクトップアプリが中心のため、監視運用の経験がほとんどない。そのため、この章の内容は「知識としては理解できるが、実感が薄い」という状態で読んだ。ただ、だからこそ知識として整理しておく価値があると感じた。実務で初めて監視設計に関わるときに、体系的な理解がなければ場当たり的な設定で終わってしまう。

それだけに、個人開発のWebサービスでこそ積極的に取り組みたいと思った。個人開発は本番障害が起きても誰も気づかないリスクがある。HTTP監視を入れるだけで「サービスが落ちていることに気づけない」問題は大幅に改善できる。画面遷移監視(シナリオ監視)まで組み込めば、認証やフォーム送信など利用者が実際に操作する機能の異常を早期に検知できる。Playwrightを使えばコードで書いたシナリオを定期実行できるため、実装コストも現実的な範囲に収まりそうだ。

また、監視の本質は「検知すること」ではなく「検知した後に何をするか」だという点が印象に残った。アラートが飛んでも対応フローが決まっていなければ、結局手が止まる。監視設計とエスカレーションフロー設計はセットで考えなければ意味がない。アラート検知テストと検知後の情報連携テストを分けて実施するという発想も、実際の現場では混同されがちな部分で、明確に区別することの重要性を再認識できた。


実践できること

  • 個人開発のWebサービスにHTTP監視を導入する
  • アラート検知後の対応フロー(誰が・何を確認して・どう復旧するか)を1枚にまとめる
  • シナリオ監視(ログイン・フォーム送信など)をPlaywrightで実装してみる
  • 監視アラート検知テストと、検知後の情報連携テストを別々に計画・実施する手順を考える
  • 個人開発のAWSリソース(ECS・RDS・ALBなど)に対してCloudWatchアラートを設定し、検知→通知→確認の一連のフローを実際に動かしてみる

定量評価(1年後に記入)

注意: このセクションは読書直後ではなく、1年後など実際の効果が見えてから記入してください。

記入日: YYYY-MM-DD

スキル・知識の評価

評価項目 評価 コメント
長期的な有用性 ⭐⭐⭐⭐☆ (4/5)
実践のしやすさ ⭐⭐⭐☆☆ (3/5)
汎用性 ⭐⭐⭐⭐☆ (4/5)

スキルスコア: /15点

経済的インパクト

投資コスト

項目 数値 根拠・計算
書籍価格 ¥X,XXX
読書時間 XX時間
読書時間コスト ¥XX,XXX
総投資額 ¥XX,XXX

リターン

項目 数値 根拠・計算
時間削減効果 XX時間/月
時間削減の金額換算 ¥XXX,000/月
コスト削減効果 ¥XXX,000/年
年間経済効果 ¥XXX,XXX
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?