スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

THE VISIBLE OPS HANDBOOK(見える運用)

THE VISIBLE OPS HANDBOOK(見える運用)
ITILの実践的な導入方法
1205070143.jpg

さんじのぱぱの仕事に使えそうな事柄を、以下にメモしました。

・推薦文から
 ITIL(Information Technology Infrastructure Library:IT保守運用のベストプラクティスの集成)の理論と実践のギャップを埋めてくれます。

裏表紙のことば
「データセンターを正しく機能させるための道のりを示しています。
 もし、運用に疲れていたら、この本を注意深く読んでみてください。」


■最初におおまかな目次
フェーズ1:変更の監視と初動の改善
フェーズ2:目録作成と脆弱な資産の特定
フェーズ3:繰り返し構築できるライブラリの作成
フェーズ4:継続的な改善
付録A:監査のための準備
 ・コントロールとは
 ・監査役-内部および外部
 ・企業改革法(2002年)
 ・「可監査性」を高めること
 ・監査役からの警告と指示
付録B:変更とパッチの管理ガイド
付録C:ITインフラストラクチャ・ライブラリ(ITIL)
付録D:統合管理能力調査(IMCA)で、焦点を絞る
付録E:用語集
付録F:構成管理データベース(CMDB)のテーブル構造
付録G:参照
付録H:高いパフォーマンスのIT組織


■印象的な文句を並べた。
 さんじのぱぱが、後日、何が本に書いてあったか探せるように。

P7
改善を妨げるのは人やプロセスなのです。

P11
何かを改善しなければならない-そうでなければ、なぜこの本を読むのですか?
「世界が破滅する最大の可能性は事故によるものであるとほとんどの専門家が認めている。

P13
普通の組織にない、高いパフォーマンス組織の特徴
 ・平均修理時間(MTTR = Mean Time To Repair)
 ・平均故障間隔(MTBF = Mean Time Between Failure)
 ・可用性
によって判別される高いサービスレベルと高いパフォーマンスを誇る運用組織のリスト;運用とセキュリティが統合され、計画外の作業が少なく、管理者一人当たりのサーバ数が多いという特徴を持っている。
①高いサービスレベルと可用性
②卓越した変更遂行能力
③運用サイクル初期段階(リリース管理におけるパッケージングやテストのような導入前の活動をするスタッフの割合)へのより多くの投資
④運用とセキュリティの整合性のあるプロセス統合
⑤遵守の姿勢
⑥協力して仕事をする関係
⑦計画外の作業の少なさ:「消火活動」を言われている計画外の作業や緊急の作業を全体の5%以下に抑えている。(普通のIT組織は35から45%)
⑧システム管理者一人当たりのサーバ数が100以上

P16
高パフォーマンスIT組織の3つの文化的共通点
①変更を管理する文化
 「変更管理は重要です。なぜなら、組織はパフォーマンスを高めるために変更を行っているからです」
②因果関係を重視する文化
 サービス停止の80%は変更に起因する。
 平均修理時間(MTTR)の80%は変更されたものを特定するために費やされる。
  →復旧活動で最初に行うことは変更に注目すること。
 ・低パフォーマンス組織は時折、直感で管理業務を行っている結果、問題解決スキルや解決の糸口を無駄にしている。
 ・マイクロソフト社の運用フレームワークの研究によると、高パフォーマンスの顧客が再起動する回数は、平均の20分の1以下。
③継続的改善の文化
 不整合を検出する監視機能を導入しており、リスクを管理する予防と検出の仕組みを持っています。

P18
高パフォーマンス組織に共通するITILプロセス
①リリースのプロセス
 このプロセス領域への投資は多くの見返りが得られる。
 なぜなら、修復に最もコストがかからない、実環境に投入する前の環境だから。
②コントロールのプロセス
 資産・構成・変更を管理する。
 ・「コントロールがあることでビジネスのスピードが落ちることはない。コントロールは車のブレーキのように、より速く走るためにある」
 ・予防と検出により、変更管理で承認されずに導入されるものを排除する。
③解決のプロセス
 インシデント管理:顧客との関係維持に責任を持つ
 問題管理:再発したインシデントの効率的解決のために、問題を既知のエラーに変える作業。
 修復活動の最初に、変更したものを元に戻すルールがある。

P22
・再構築か、修復か。
 高パフォーマンスの組織は、修復よりも、文書化された標準の構築手順による再構築を選ぶ。

【フェーズ1:変更管理】
P25から
・計画外の作業を全作業の25%以下に抑える。
 「見える運用」の最初フェーズは、不足している医療資源を割り当てる患者分類システム(triage sysytem)に似ている。
  最初のフェーズの主な目標は、環境を安定させ、果てしなく続く緊急対応を、問題の根本原因を追及するプロアクティブな活動に変えること。そのために、数多い計画外の作業を減らす必要がある。
 それには、
 ①アクセスを制限あるいは禁止する。
 ②新しい変更ポリシーを文書化する。
 ③利害関係者に②を知らせる。
 ④変更時間帯を作る。(例:すべての変更は土曜日か日曜日の3時から5時に行う)
 ⑤プロセスを強化する。

P34
変更を評価する際の質問リスト
①誰?
 ・変更によって影響を受けるのは(失敗した時を含め)誰ですか?
②何?
 ・どの資産が変更の対象ですか?
 ・変更の後に検証すべき業務プロセスは何ですか?
 ・変更しないと何が起きますか?
③いつ?
 ・変更の効果はいつ表れますか?
④どのように?
 ・どのように変更の成功を検証しますか?
⑤もしも?
 ・変更が失敗した際の、切り戻し計画はありますか?
 ・この変更に伴う最悪の結果は何ですか?

P35
変更管理ですべきこと、すべきでないこと
<すべきこと>
・導入後のレビューをする。
・変更諮問委員会(CAB = Change Advisory Board)には証人の判断に必要な人が全員出席していること。
・変更の結果を分類記録する。
  A.変更要求の撤回(失敗と扱わない)
  B.中止、変更の失敗
  C.成功
<すべきでないこと>
・切り戻しの計画がないのに変更する。
・調べもしないで変更を承認する。

P36
変更管理が進化してゆくプロセス(①から⑦へ進化してゆく)
①変更に気づかない (例:そのスイッチングハブをリブートしたか?)
②変更に気づく (今、誰かそのスイッチをリブートしたか?)
③変更を知らせる (そのスイッチをリブートするから、問題があるなら教えてくれ)
④変更を承認する (そのスイッチをリブートする必要がある。誰の承認が必要だろうか?)
⑤変更を予定する (そのスイッチをリブートしたいが、次のメンテナンス日程はいつだったか?)
⑥変更を確認する (障害管理記録から、そのスイッチのリブートが予定どおりなされたかどうかがわかる)
⑦変更を管理する (保守アップグレードに合わせて、再来週にそのスイッチのリブートを予定しよう)

P38
すべての変更が管理されているという事実が、変更を意識させ、その意識が組織全体に波及する。

【フェーズ2:構成管理】
実環境の資産目録を作成し、維持します。
・資産目録は、インフラストラクチャに対する変更の記録や、構成情報を提供してくれる。
・変更管理する際に、資産の変更履歴や相互関係から、変更を管理できる。
・壊れやすい構成アイテム(CI=Configuration Item)を知ると、それに対してはいかなる変更もしないと決められ、リスク低減できる。


【フェーズ3:繰り返し構築できるライブラリの作成】
修復するより、低コストで簡単に再構築できるデータセンターにする。

・再構築の利点
 ①再構築手順を文書化しておけば、修復よりも自動化されたプロセスにより実行できる。
 ②故障→修復のサイクルでは新たに構成の不一致(不整合)が生まれる可能性があるが、再構築ではそれが少ない。
 ③文書による再構築作業は経験の浅いスタッフが実行でき、熟練スタッフを緊急対応から解放できる。
 ④ ③により熟練スタッフを新たなプロジェクトに取り組んでもらえる。
 ⑤実環境と全く同じテスト環境を構築できる。

・職務分離(Separation of duty、Segregation of duties)
 開発者とリリース管理エンジニアは、実(本番)環境へのアクセスを禁止する。運用チームだけが実環境にアクセスできる。

P59から
【フェーズ4:継続的な改善】

・環境を安定させ、緊急対応を減らす。これにより組織のニーズに取り組める(変更に使える)時間が増える。
・指標を使って、継続的な改善活動に使う資源を上手に割り当てる。

「努力のないビジョンは夢でしかない。
 ビジョンのない努力は単純労働に過ぎない。
 ビジョンをもって努力すれば希望の世界がある」

「マネジメントの原則:計測できないものは管理できない」

・運用業務でキーとなる指標は、可用性の指標(MTTRやMTBF)です。
・指標の分析結果を使って、次のように、より高い次元の課題に取り組む。
 ①キーとなるスタッフを、修復に最もコストの掛からない導入前の業務へ移す。(導入後のトラブル対処はコストが掛かるので、そこに割り当てずにすむように、フェーズ3までの実践で可能にする)
 ②計画外のリアクティブな作業の代わりに、プロアクティブな計画的作業に時間を費やす。
 ③成功する変更によりIT資産のビジネス上の価値を高め(使い勝手の良いシステム)、組織の生産性を向上させる。

P65
デミングの名言
「プロセスでしていることを説明できないのは、何を行っているかが分かっていないのだ」
「ベストを尽くすだけでは十分ではない。すべきことを理解してからベストを尽くしなさい」
「経験が助けになるって? やり方が間違っていれば、助けにはならない」
「プロセスの結果に注目するのではなく、その結果を導いたプロセスに注目しなさい」
「学ぶことは義務でなく、生き残るための手段なのだ」

P67
・監査役は、効果的なコントロールが存在することを確認するための、リソースであると、ITチームは考える。
・監査役の視点(リスクとコントロール)
  予防:何かが起こらないようにコントロールする。(職務分離、承認プロセスなど)
  検出(発見):監視活動。予防コントロールの失敗やルール違反がないか?
  補正:期待されている状態に戻す。

P68
・IT全般統制(機械・システムのコントロール)のわかりやすいたとえ。
 監査役と「豆を数える人」は、かつて、倉庫の豆を数えて財務報告が正しいことをチェックしていました。
 しかし、チェックのための資源(監査役と「豆を数える人」の人数や時間)には限りがあります。
 そこで、豆を数える代わりに、豆を数える機械が信頼できるか否かを、予防と検出のコントロールを組み合わせて判断し、信頼できる機械と判断することで、財務報告が正しいとした。
 ところが、機械のコントロールが不十分で機械が信頼できないとなると、豆を数えなければなりません。

P70
・監査役は、監査に合格するためだけに監視機能を保持している組織を見たくありません。
 むしろ、ビジネスを改善するために監視機能を大切にする組織に出会いたい、と考えています。

P78
・リスクに対応(低減・受容・回避・移転)するプロセスがあること。
スポンサーサイト

テーマ : 最近読んだ本
ジャンル : 本・雑誌

コメントの投稿

管理者にだけ表示を許可する

プロフィール
・思うこと、こころ動かされたこと。
・そもそも、あたりまえのこと
 を考えながら書いてゆきます。

さんじのぱぱ

Author:さんじのぱぱ

最新記事
月別アーカイブ
カテゴリ
カウンター
検索フォーム
RSSリンクの表示
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。