今後のシステム運用の考え方を自分なりにまとめてみた！

1. キャパシティ管理

1.1 基本的なキャパシティ管理の考え方

下記、3つの指標を"計測"した状態で"バランス"を保っていく必要があります。
いづれかの指標が崩れた監視運用になっていないかを確認することが監視マネジメントの基本となります。

1. 業務量
2. リソース（コスト）
3. サービス

上記のバランスを取っていく為に、どのような活動を実施すればよいのか。

1. プロアクティブな改善
   クライアントより先に劣化検知し、受け身にならない改善を常に実施していく。
2. 性能問題の迅速な解決
   検知した問題を迅速に解決し、属人化させずナレッジ化する。
3. 急激なアクセス増加
   ユーザ通知で満足度維持 / 即時リソース追加等
4. 無駄なリソース投資の発見
   クラウドサービスの利用でコスト削減

1.2 現状と未来

現状	未来
計測のサイロ化 / 情報の散在	状況の完全な可視化
アラートストームで開発に専念できない	適切なアラート管理で開発に集中
現場の高齢化 / スキル不足	ナレッジ化 / ノウハウ化 / 教育体制
無駄な定例 / 読まれないレポー	情報に基づく分析 / プライオリティを決めた情報発信
IT費用の拡大	クラウド活用によるITコストの最適化 / 新規施策への挑戦
経営人と現場でのDXの認識のズレ	インテリジェンスを意識した経営陣の意思決定

2. 運用のあるべき形

2.1 フレームワーク

• ITIL v2
  • 業務フローが定義、導入しやすい
  • 個々のプロセスの有効性、効率性
  • 運用現場中心のフレームワーク
• ITIL v3
  • ビジネスをITで解決する
  • 正常稼働ではなく、提供価値に注目
• ITIL v4
  • 企業活動とITを分けずにとらえる
  • 組み換え可能なシステム構成
  • 会社全体で取り組んでいく姿勢

フレームワーク	目的
ITIL	堅牢性：壊れないことを前提にシステム構築
DevOps	故障前提：壊れることを前提にシステム構築
SRE	回復性：故障時の復旧を見越してシステム構築(アプリレイヤーを含む)

2.2 ITへの期待

• 間違いなく動き続ける → 素早くビジネスを立ち上げる
• 正しく動き続ける → 効果が測定できる

2.3 性能管理

• リソース
  リソース調達コストは減 / 調達スピードは高速化
  ⇒リソース管理の価値は相対的に低下
• 業務量
  現場の業務量がダイナミックに変動する
  ⇒ 業務量計測がビジネス成功 / コスト最適化のカギとなる
• サービス
  システムの正常稼働を示す指標として、サービスの計測、可視化が重要性を増す

上記から、業務量のみが外的要因によって変化する値であり、可視化が必須なKPIとして位置づけられる。

3. サービスについて

3.1 基本的なサービス管理の考え方

• 目的
  • ユーザ部門へ提供するITサービスの品質管理を行う
• ITサービス
  • 計測可能であること
    ⇒ レスポンス時間/パッチ終了時間/使用可能度/..…など
• 実施作業
  • ユーザ部門との合意としてのSLAを明確化する
  • ITサービス状況を計測し、定められたSLAを満たしているかを監視し報告する
• 計測データを適切な手法で集約する
  • 平均值 or 最大值/ピーク時 or 全時間帯/...など
• SLAもしくはSLOに違反した場合を問題として捉える 問題発生時には必要に応じてチューニングを実施する
  ⇒ ITサービスをSLA内に収めることが目的
• ボトルネック
  • 一つ改善してもボトルネックは一生消える事無く常に移動し続けるという事実。
    　⇒ 常に改善を！

3.2 基本的な指標

1. SLA
   サービスの提供事業者とその利用者の間で結ばれる、サービスのレベル（定義、範囲、内容、達成目標等）に関する合意サービス水準
2. SLO
   事業者が設定するサービスに関する目標
3. SLI
   サービスの動作を直接測定したもので、システムのプローブが成功した頻度

4. ワークロード

4.1 ワークロード管理の基本的な考え方

• 目的
  • 業務量の増加予測
  • 業務量増加に伴うリソース不足時期の把握
• 実施作業
  • 2種類の業務量を収集する
    • システムから見た仕事量 (ワークロード)
      例) トランザクション数
    • ユーザから見た仕事量 (ビジネス指標)
      例) 業務を正しく分類する
• 将来を予測する
  • ワークロードの増加傾向を予測する
    例)売り上げ、契約数、システムの利用者数
  • ワークロード増加に伴う不足リソースを把握する

5. リソース

5.1 リソース管理

• 目的
  • 的確にボトルネック箇所を把押し、必要に応じたチューニングの実施
• ボトルネックとは?・・・待ち
  • 性能低下の要因が全体から見れば小さい部分にあり、かつ他所をいくら向上させても状況改画されないような場合、その原因菌所をボトルネックと呼ぶ。
  • ボトルネックは性能低下の原因となるほかりか、ワークロード管理などの将来予測の精度を著しく低 下させてしまう。
  • ボトルネックを解消すると別の箇所がボトルネックとして潜在化する
• 定期的な実施作業
  • リソースの余力を管理
  • 性能分析(ボトルネックの把握)
  • 必要に応じたチューニング

5.2 リソース調達の考え方

古い考え方

• ハードウェアの調達には (数か月単位の) 時間がかかる
• リソースは高価で途中での追加には大きな工数がかかる
• 稼働期間中の構成変更は行わない(例外的にサーバ追加での補強はある)

つまり・・・資源計画、キャパシティブランニングが重要

これからの考え方

• クラウド、仮想基盤ではリソースの調達は瞬間的にできる
• リソースの追加、削減は動的に変更可能
  (クラウドでは従量課金なので使わなければコスト削減につながる)
• 稼働期間中の変更も柔軟に対応できるように抽象化が進んでいる
  (OSやパッケージのバージョンからの解放案としてのコンテナやSaaSの隆盛)

つまり・・・稼働データから必要量の設定をするほうが簡単、且つ正しい設定がしやすい