はじめに
タイトルの通りですが、運用って意外に難しいですよね。
仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか？
- 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...？
- ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
- ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば
システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。
読んだ本
もくじ
- 詳細設計フェーズ
- 4.1.詳細設計
- 4.2.監視設計
- 4.3.バックアップ設計
- 4.4.ログ設計
- 4.5.自動化設計
「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。
読んだ感想
この章では詳細設計における運用設計とはという形で説明されています。
運用フローや運用手順書でつまづく事が多かったために本書に手を伸ばしたこともあり、
* 「誰が」「いつ」「何をきっかけに」「何の作業を行う」 * 「手順書」や「台帳/一覧」がマッピングされてると良いフローになる
の考えは失敗体験の後に読むと非常に身にしみる章でした。
4.1.詳細設計
ソフトウェア設計では「内部設計」、「プログラム設計」を行うフェーズ。
運用設計では以下を行う
- 運用フロー
- 運用手順書
- 台帳/一覧
運用フロー
- 「誰が」「いつ」「何をきっかけに」「何の作業を行う」を記載
- 「手順書」や「台帳/一覧」がマッピングされてると良いフローになる
- 運用フローの種類
- UMLアクティビティ図
- 業務の流れを可視化する
- BPMN（Business Process Modeling Notation）
- ビジネスプロセスの可視化をする
- 作成時の注意点
- イベント発生トリガー
- 申請なのか、障害検知か、定常作業か
- 登場人物の情報連携方法
- インプットとアウトプット情報を取りまとめる
運用手順書
- 作成ポイント
- 粒度を決めておくと良い
- 細かすぎると手順が煩雑になる
- 場合によってはコマンドの羅列でも良い
- 作成者
- 運用フローを実施するにあたって必要となる手順を記載する
- すべての運用手順書を作ろうとしない
- インフラ、アプリチームと分担する
- 手順書のとりまとめ、運用担当者へ引き継ぐことが役目
台帳/一覧
- 一覧
- 静的データをまとめたもの
- 台帳
- 動的データ、定期更新があるデータ
- 例
- IPアドレス一覧
- サーバ構成管理票
- ソフトウェアライセンス一覧
4.2.監視設計
監視の目的
正常に稼働しているか、停止の予兆はないかを確認し、障害時になるはやで対応できるようにしておく事
監視設計とは
- 設計するもの
- 監視対象
- 監視方法
- 監視オペレータへの通知方法
- 監視種別
- サービス監視
- アクセスして正しく表示されるか
- サービスを直接関しするため、異常検知の場合の緊急度は高い
- 例
- HTTP監視
- 画面遷移監視
- インフラ監視
- 構成要素の監視のため、サービスに影響がない場合もある
- 冗長化されてるなど
- 例
- ハードウェア監視
- リソース監視
- プロセス監視
- ログ監視
- error以上を監視対象
- warnは確認する程度
- 監視設計の勘所
- 障害検知後に、何を基にどのように動くかを決めておく
- 監視の運用体制
- 営業時間内/外
- 社内/外
- 監視ツールの選定
- 監視サーバの配置場所
- 製品リモート監視サービス
- 監視業務のアウトソース
- 監視システムのテスト
4.3.バックアップ設計
バックアップ設計とは
- 設計するもの
- 取得周期
- 取得世代
- 復元方法
- 前工程（基本設計）で決まっているもの
- バックアップ対象
- 取得先
- バックアップ方法
- 指標
- RTO
- 目標復旧時間
- 障害が発生してから復旧までにかかる時間
- RPO
- 目標復旧時点
- 障害発生時間からどのくらい前のデータに復旧できるかの時間
- ポイント
- 短いほどいいがコストがかかる
- 高可用性が求められる
バックアップ種別
- 種別
- システムバックアップ
- サーバOSまるごとバックアップ
- パッチ適用時などOS領域に変更が加わる際に取得
- データバックアップ
- データやログ、データベースが対象
- 取得周期はRPOと同一になる
データリカバリ
- リストア
- バックアップデータを復元すること
- リカバリ
- 障害発生直前の状態に復旧すること
- リストア後に、必要な設定変更の実施、差分パッチを適応する
バックアップ計画
- バックアップ方針項目
- 目的
- 障害/火災対策、構成変更時、など
- バックアップ対象
- 物理/論理、構成ファイル、DB、ログ、など
- 取得世代数
- 保持期間、取得回数
- データ量
- バックアップする総サイズ
- バックアップ対象 x 世代数
- 取得時間 − 取得可能な時間帯
- バックアップウィンドという
- バックアップ方法
- フル、差分、増分
- 取得媒体
- テープ、専用ストレージ、仮想テープ装置
- 費用
- 初期費用、月額、追加料金
バックアップ技術
- 重複排除
- バックアップの冗長データを削除することでバックアップのデータ量を少なくする技術
- データを加工して格納するので、そのままデータをバックアップするより時間がかかる
- スナップショット
- ストレージ内のデータや仮想環境のマシンのある瞬間をイメージとして複製すること
- ディスク障害でデータが消えるとスナップショットも消える
- 消去する際に負荷がかかる
- 作成後長期間放置すると更新情報が多くなりデータ量が大きくなる
- レプリケーション
- 本番系のデータをリアルタイムに待機系に複製する
- 障害発生時は自動で瞬時に待機系に切り替える事でサービスを継続する
- RTO/RPOもほぼゼロになる
- 本番と同じシステム構成の維持のため、費用が高い
4.4.ログ設計
ログ
- 障害調査用
- 障害箇所の特定や影響度の調査目的
- 期間は短くても良い
- 監査対応用
- 情報流出や不正アクセスの調査目的
- 期間は長く保存する
ログ管理サーバ
- ログの一元管理
- サーバや機器側での保存が必要なくなる
- ログの分析・レポート
- 今何が起きているか、過去に何が起きたかを確認できる
- ログの圧縮
- 長期間保存する場合は圧縮を行う
- ログのモニタリング
- リアルタイムに監視し、問題があればアラートをあげる
- ログの原本管理、改ざん防止機能
- 改ざんの検知
4.5.自動化設計
- 自動化設計とは
- 自動化に適した作業を洗い出し、どのように自動化するか検討する
- タイミング
- 基本設計段階
- 運用開始後
- 自動化の効果が出やすい
- 自動化のメリット
- 工数削減
- 作業品質の向上
- スピードアップ
- 属人化排除
- 運用中に自動化する時の注意点
- 自動化の前後で作業時間を計測し効果測定する
- 自動化対象の選定ポイント
- 作業頻度
- 目安は月一回以上やる作業
- 頻度は少ないが、誰がいつやっても同じ品質を担保したいもの
- 作業時の判断数
- 作業時に人の判断がたくさん入る作業は向いてない事が多い
- 作業コンポーネント数
- 複数コンポーネントにまたがる場合も向いてない事が多い
- 作業確実性
おわりに
エンジニアということもあり
監視やログといったシステム寄りの部分は触れる事が多いのですが、
運用フローや運用手順書となると意外にナレッジが自分に少ない！
その辺りまで考慮した進め方ができるようになれたら本当にすばらしいですね＼(＾o＾)／
紹介
