20120308-forschooner-seminor¶
運用ドキュメント ことはじめ (大久保さん)¶
- 同じ事をよく聞かれる
- いつの間にか保守切れている
なぜそうなる¶
- きいたほうが楽
- どうすれば良いかわからない
メリット¶
- その人が仕様 からの脱却
- 可視化 状態
- 可視化 業務
整備例¶
- 設計書
- 構成図
- 仕様書
- バックアップ
- 監視
- 体制図
- 手順書
- 定型手順
- 障害対応手順
- 作業/障害管理票
- 環境定義 (構成情報の一種)
- 管理台帳
意識すべきポイント¶
- レイヤー
- ソフト/ハード
- 管理
モデルケース¶
- 前任者がいない
- ドキュメントがない
- 社内向けシステム
- 社外向けシステム
- 必須
- 運用手順
- 資産管理
- できれば
- 理想
運用資料¶
- システムリスト
- 関係者リスト
- 物理資産
- アクセス手段(アカウント)
調査/ヒアリング
- 利害関係者のあらいだし
- 窓口、連絡先
- 外部ベンダーのサービス条件調査
管理対象の把握
- 保守情報
- 棚卸/現地
- 保守ベンダーの窓口
運用手順書
- 手順書
- 完了条件を意識する
- 異常時の切り戻しの方法も考慮
環境の定義、運用仕様書
- 調査目的
- 調査計画
- リスト
- 環境定義
- 調査方法
- 調査計画と手順は使い回せるように残しておく。
理想¶
- 運用設計
- システム構成図
24/365運用の技術¶
止まることは機会損失
人がやるのは負担が高い、システムで補完しよう。
- 監視 (障害監視)
- 通知が主目的
- 項目の定め方
- 内と外
- レイヤー
- モニタリング (データ測定)
- スケーリング計画のベース
- Munin
- 自動化
- IaaSをつかった障害自動回復の実例はあるか?
- アメリカでもあまり実例がない?
- 状況把握に一番時間かかる
- そこを自動化できないか?
- DevOps について
- 発展途上
- スタートアップだと自然にDevOpsになっている。
- はやいデプロイ、はやいリリース
- 5分でIaaSはたちあがる。
- 人はついていけてない。
- ネットゲームには "運営者" というサービス判断をする人がいる。そこは人でしかできない。
- 障害時は、すぐあやまりに来るよりも
- 再発防止策/情報共有などのコミットの方が大事