掲示板

T22に向けて作成中のデータ - セントラル越前 - 2017/10/25(Wed) 23:31:03 [No.3]

└

越前藩国の高速道路事情 - セントラル越前 - 2017/12/03(Sun) 19:44:02 [No.149]

└

生活施設　○洋菓子店　RD12 評価値6 - あずむ - 2017/12/01(Fri) 01:14:26 [No.147]

└

大部品調整版 - あずむ - 2017/12/01(Fri) 13:13:26 [No.148]

└

赤鰯（仮）※部品項目のみ - セントラル越前 - 2017/11/24(Fri) 03:14:55 [No.132]

└

白兵戦用簡易ウォードレス・ピーナッツ（作成中） - セントラル越前 - 2017/11/23(Thu) 02:11:18 [No.128]

└

白兵戦用簡易ウォードレス・ピーナッツ（完成） - セントラル越前 - 2017/11/24(Fri) 03:09:35 [No.131]

└

ショウ・ジ（途中） - セントラル越前 - 2017/11/22(Wed) 22:37:14 [No.127]

└

越前中央病院 RD:38 評価9 - 黒埼紘 - 2017/11/21(Tue) 04:22:45 [No.126]

└

舞龍（仮） - セントラル越前 - 2017/11/20(Mon) 21:17:58 [No.123]

└

Re: 舞龍（仮） - セントラル越前 - 2017/11/21(Tue) 00:16:34 [No.124]

└

地形反映時に修正した部品 - 黒埼紘 - 2017/11/19(Sun) 22:51:46 [No.118]

└

チェックしました - セントラル越前 - 2017/11/19(Sun) 23:11:28 [No.119]

└

地形に反映しました - 黒埼紘 - 2017/11/19(Sun) 23:27:54 [No.120]

└

越前藩国の住宅事情 - セントラル越前 - 2017/11/19(Sun) 20:21:21 [No.117]

└

藩国地形更新 RD:223　評価値:13 - 黒埼紘 - 2017/11/19(Sun) 05:55:06 [No.114]

└

藩国地形更新 RD:126　評価値:11 - 黒埼紘 - 2017/11/18(Sat) 03:10:46 [No.107]

└

空挺剣士　※部品項目のみ - セントラル越前 - 2017/11/17(Fri) 00:07:16 [No.101]

└

空挺剣士　※作成中 - セントラル越前 - 2017/11/21(Tue) 00:45:56 [No.125]

└

店舗類追加３点 - 黒埼紘 - 2017/11/16(Thu) 00:45:29 [No.96]

└

残りの地形類　RD9 - あずむ - 2017/11/15(Wed) 23:25:18 [No.95]

└

空島トンネル/越前街道/○畑作・畜産区域 - あずむ - 2017/11/15(Wed) 21:54:34 [No.94]

└

〇越前藩国の中央区　RD8 評価値5 - あずむ - 2017/11/15(Wed) 19:47:35 [No.92]

└

[削除] - - 2017/11/18(Sat) 03:09:52 [No.106]

└

〇越前藩国の中央居住区　RD7 評価値5 - あずむ - 2017/11/15(Wed) 17:33:36 [No.91]

└

越前警察署 - 黒埼紘 - 2017/11/14(Tue) 00:50:32 [No.84]

└

データセンター（施設）※部品名のみ - セントラル越前 - 2017/11/13(Mon) 20:55:29 [No.83]

└

Re: データセンター（施設）※作業中（RD47) - セントラル越前 - 2017/11/14(Tue) 00:58:15 [No.87]

└

データセンター（施設）※一旦完成（RD107) - セントラル越前 - 2017/11/29(Wed) 22:41:56 [No.146]

└

越前情報軍（組織） - 黒埼紘 - 2017/11/12(Sun) 01:47:58 [No.78]

└

電脳迷宮 - セントラル越前 - 2017/11/11(Sat) 23:10:54 [No.76]

└

越前藩国奨学金制度（途中まで） - セントラル越前 - 2017/11/10(Fri) 01:35:03 [No.66]

└

越前藩国奨学金制度（一旦完成） - セントラル越前 - 2017/11/11(Sat) 02:34:56 [No.72]

└

〇越前藩国奨学生 - セントラル越前 - 2017/11/09(Thu) 23:51:16 [No.65]

└

店舗系進捗　※途中 - あずむ - 2017/11/08(Wed) 22:54:30 [No.63]

└

Re: 店舗系進捗　※途中 - あずむ - 2017/11/12(Sun) 23:24:48 [No.79]

└

Re: 店舗系進捗　※途中　遊園地＋飲食 - あずむ - 2017/11/14(Tue) 15:24:06 [No.88]

└

店舗系進捗　※一旦完了　服飾系 - あずむ - 2017/11/15(Wed) 00:16:27 [No.89]

└

〇鮫島造船工房 - セントラル越前 - 2017/11/07(Tue) 23:22:32 [No.59]

└

〇温暖湿潤気候 - 黒埼紘 - 2017/11/07(Tue) 00:39:21 [No.55]

└

〇越前藩国の標準的な教育カリキュラム（T22）※初版 - セントラル越前 - 2017/11/06(Mon) 21:45:52 [No.51]

└

○越前藩国の民(T22)　※仮版 - セントラル越前 - 2017/11/06(Mon) 00:11:41 [No.47]

└

○越前藩国の民(T22)　※修正１ - セントラル越前 - 2017/11/06(Mon) 22:08:32 [No.52]

└

所在地情報だけあれば大丈夫な地形類 - あずむ - 2017/11/05(Sun) 16:06:18 [No.45]

└

○地下鉄　※途中 - あずむ - 2017/11/03(Fri) 22:03:43 [No.28]

└

○地下鉄（初稿） - あずむ - 2017/11/04(Sat) 17:48:56 [No.40]

└

○地下鉄（追記・修正） - あずむ - 2017/11/05(Sun) 14:05:52 [No.44]

└

○地下鉄　RD23　評価値7 - あずむ - 2017/11/15(Wed) 20:10:34 [No.93]

└

ショッピングジャングル「ラ・マンチャ」　※途中 - あずむ - 2017/11/02(Thu) 23:16:36 [No.26]

└

○ショッピングジャングル「ラ・マンチャ」　RD10　評... - あずむ - 2017/11/03(Fri) 19:27:21 [No.27]

└

〇降下用サーフシールド - セントラル越前 - 2017/11/02(Thu) 00:02:59 [No.25]

└

○越前藩国の離島（砂島・泉比良島）　RD6　評価値4 - あずむ - 2017/10/31(Tue) 21:44:40 [No.23]

└

○イワヤト温泉郷　RD9　評価値5 - あずむ - 2017/10/30(Mon) 20:42:50 [No.20]

└

システム運用技術　RD58 評価値10 (10/30時点) - セントラル越前 - 2017/10/26(Thu) 21:12:41 [No.14]

└

ＥＡＩシステム - セントラル越前（代理） - 2017/10/25(Wed) 23:33:29 [No.6]

└

〇越前藩国の農村地区 - セントラル越前（代理） - 2017/10/25(Wed) 23:32:33 [No.5]

システム運用技術　RD58 評価値10 (10/30時点) (No.3 への返信) - セントラル越前

※適宜更新中です

システム運用技術
〇システム運用技術の概要
システム運用技術とは
システム運用技術とは、コンピュータを利用した様々なシステムを使用するにあたり、安定してサービスを提供できるように理論や経験をもとに体系化されたノウハウ集である。

絶対の指針ではない
システム運用技術は机上の理論と過去の蓄積を組み合わせて作られたベストプラクティスであり、「こうすべき」という規定や指針ではない。それぞれの環境に合わせてカスタマイズすることで効果を発揮することになるだろう。

とはいえ安定稼働のためには必要
コンピュータシステムの健全な利用のためにはセキュリティ対策一辺倒ではなく、日頃から適切な運用が行われて初めて安定して利用することができるのである。システム運用技術は日常的な安定稼働のために必要な技術として捉えられている。

習得までにかかる年月
システム運用技術の習得にはオーソドックスな理論と現実に存在するコンピュータシステムの知識、そして自身の経験をも要求する。基本的な技術力を前提として最低１年の机上での講習と２年間の実習、さらに３年間の実務を経て初めて身についたと言う事が出来る。

〇システム監視と障害対応
システム監視運用とは
監視運用とはコンピュータを使用したシステムや業務で異常が発生したことを素早く検知することを目的とした運用業務、及び仕組みのことである。

障害対応とは
障害対応とは、システム監視によって検知された異常を回復する際に行われる対応である。本来的には両者は別の分類ではあるが、現場の業務では区別しづらい場面もあり、合わせて語られる事も多い。

異常の種類
一口に異常と言ってもその種類は星の数ほどあり、無視していいものから即座に対応する必要があるものまで千差万別である。

捉えたい異常をはっきりと定める
起きると困ったことになる『異常』とは何なのか、ということをはっきりと定めることが監視運用のスタートである。

最初はある程度大雑把に決める
とはいえ起こりうるすべての事象をあらかじめ予測して定義することは不可能なので、ある程度大雑把に『異常』の範囲を決め、実際に運用をしながら絞り込んでいくことがベターである。

異常の重要度を決める
発生することが想定される異常の中には急いで対応すべきものや、重篤な影響が出る前に早めに知らせてほしいもの、とりあえず起きたことけ記録しておきたいものまである。そうした意図に従い、検知時に重要度をセットで通知することも重要である。

過去の知見を活かす
同じようなシステム構成が他にあれば、その運用実績を生かして同じような監視設定を行うことで定義漏れを減らし品質を高めることも可能である。

異常の発生を捉える
事前に定義した異常事態が発生したとき、それに気づけるようにするために監視用のソフトウェアを使用する。もしくは定期的に人が目で見に行く、というやり方もある。

異常が起きたときの対応
異常が発生したときにどうすればいいか、という点もある程度事前に決めておく必要がある。回復手順が確立できるのであれば手順書や自動回復プログラムを、そうでない場合には詳しく調べられる人に連絡する、などである。

異常発生時の連絡先
異常発生時の連絡先は、万が一連絡が付かなかった時のために複数人の連絡先を登録しておくケースが多い。深夜寝てる時に電話がかかってきても必ず起きられるとは限らないからだ。

影響の確認
対応方法が確立されていないような異常が発生した場合、まずはそのシステムや業務が正常に動作しているかを確認する。停止していれば緊急性は何段階か上がるが、逆に正常であれば緊急性は低い、などと判断できる。

事象の切り分け
発生した異常の内容や原因を調べながら、問題の発生した部分を切り分けていく作業がある。事前に決めた監視の種類によって見ただけですぐ分かる物から腰を据えて調べないと分からないものまである。

過去の対応結果の確認
発生した異常と同じような事象が過去にも起きていたかを確認するのも異常の特定や対応に有効だ。もし同じ事象を過去にも対処していたことがあれば、その内容を参考に今回も対処することができるからだ。

対応内容の記録
異常発生の連絡を受けてから対応完了までの間、やったことや調べたことはしっかりと記録する。進捗管理という面もあるが、将来似たような異常が起きたときに参考になるためだ。

ワークアラウンド
発生した異常の原因がつかめないまでも、とりあえず正常に動くようにできる方策をワークアラウンドと呼ぶ。しばらくは応急処置で時間を稼ぎつつ、根本的な対応を検討する時に使う。

〇問題管理
問題管理とは
問題管理とは、システム監視によって検知された異常や、ユーザーからの問い合わせ等で発覚した異常など、システム稼働への影響度が大きい問題が解決するまでを管理する運用である。

なぜそんなことをするのか？
システム運用の現場は意外と忙しく、発生した異常への解決がなあなあで済まされてしまったり、うっかり忘れてしまった結果同じ問題を起こしてしまう事がある。そういう事が起こらないよう、影響度の高い問題は確実に解決できるように管理する必要があるのだ。

問題の記録
問題管理においては、問題の発生した日時や発生したシステム、影響度と影響を受けたユーザー、対応優先度、発生した問題の詳細情報や実施した対応、そして最終的な解決手段までが記録される。

原因調査と特定
ワークアラウンドで影響を回避できても、原因が解消できていなければ再発の可能性は常にある。問題管理においては、まずしっかりと調査して原因を特定する事になる。

解決策のレビューと実行
問題の原因が特定でき、解決策の準備ができたら他者のレビューを受けた上で実際に実行する。技術的な見落としはもちろん、経営や業務へのインパクトを最小にするために、上位職層もレビューに参加することがある。

問題のクローズ
解決策の実行が完了し、問題のトリガーとなる事象が発生しても問題が発生しないことが確認できれば問題管理上ではクローズとなる。検証が困難な場合には、一定期間の経過をもってクローズされる場合もある。

プロアクティブな問題解決
同じようなシステム環境が複数存在していれば、特定のシステムで発生した異常は他のシステムでも起きる可能性があると言える。原因を突き止めた上で、他に同じ問題を起こしうるシステムがあれば、それらに対しても未然に解決策を実行することも重要である。

〇変更とリリース管理
ニコイチで運用
元々は変更管理とリリース管理という別の枠組みだが、実業務では個別に運用することは少ないため合わせて「変更リリース管理」と呼ばれることもある。

変更管理とは
システム構成やオペレーション内容など、システムの利用と運用に関わるものの追加・修正・削除をコントロールすることを変更管理と呼ぶ。「実際に変更すること」は変更管理では管理しないことに注意。

変更管理の対象
システムによって提供される業務などのサービスに何らかの影響を与えうる変更は全て変更管理の対象となる。ただし、本当に全部管理すると作業量が爆発するので、影響度が低い、実施部門が異なる、などの明確な指針を立てて適用対象外にしたり管理を簡素化している。

変更の要求
変更が必要となった段階で行われるのが変更の要求であり、その活動を記録するために専用のレコードが起票される。実運用ではワークフロー化されていることも多い。

変更のアセスメント
変更を計画する際、その計画が目的に対して十分であるか、失敗時のインパクトやその対策が考えられているか、等が評価される。問題があれば計画は差し戻されるが、承認されればテストへと移ることになる。

重視されるポイント
変更のアセスメントでは「誰が提起したのか」「変更によって発生する影響」「変更しないことによる影響」「他の代替策ではない理由」「変更時に必要となるシステム停止時間とその計画」「変更に必要なリソース」「失敗した時の切り戻しパターン」などが重要視される。

変更内容のテスト
計画が承認された後で実際にテストが行われる。順番が逆かと思われるかもしれないが、未承認状態でテストした結果テスト環境がとんでもないことになった、とかだと目も当てられないので、こういう順番になっている。

テスト結果の評価と承認
実際に行ったテストが当初の目標を達成し、他に問題を起こさないことを確認・評価された所で、改めて本番環境に対して展開することが承認される。

変更諮問委員会
変更諮問委員会とは、変更管理においてアセスメントを満たしているかをチェックする機構である。技術職のみならず管理職や規模によって経営層も参加することがある。

定例会と臨時招聘
変更諮問委員会を構成するメンバーは基本的には固定化し、週１回などの頻度で定例開催すると効果的である。定例会に間に合わないような緊急の変更については一部メンバーだけ招聘して開催することもある。

リリース判定も兼ねる
変更やリリースの承認で何度も諮問委員会に諮るのは実運用としても大変なので、変更諮問委員会で変更管理とリリース管理を兼ねる場合もある。その際でも、計画やテスト等の各ステップでのチェックは有効に機能するよう仕組みやルールを作る必要がある。

リリース管理とは
リリース管理とは、変更管理等で承認を受けたシステム構成要素の追加・変更・削除を問題なくリリースできるようコントロールすることを目的とする。実際の作業はこちらのリリース管理で面倒を見ることになる。

管理の主な項目
リリースを管理するにあたり、その作業がどのような規模で、どれくらいの重要度なのかを定義する。変更管理でも同じようなことをしているので基本的にはこれを引き継ぐが、実運用では障害対応の回復手順としてシステム変更を行ってしまうこともあり、事後承認という形で記録を残すこともある。

リリース計画と承認
本番環境へのリリースを行うにあたり、利用者をはじめとする関係者と作業日程を調整したうえで計画化し、その承認を得る必要がある。

リリースと正常性の確認
本番環境にリリースされた後はそれで終わりという訳ではなく、変な悪影響が出ていないかという点をしっかり確認する必要がある。それが終わって初めて変更とリリースは完了となる。

しくじった場合
事前の計画やレビューで潰したはずなのであってもらっては困るものの、実際のところリリースした変更が原因で別のトラブルが起こることはある。そういう時はアセスメントに従って事前準備されているであろう切り戻し手順に従って変更前の状態に復旧させなければならない

そして問題管理へ
リリースでしくじって問題を起こしてしまった場合、改めて問題管理を起票して原因を特定しなければならない。再発防止に加えて、正しい変更手順を作り直すことでようやく変更管理、そしてリリース管理をやり直すことができるようになる。

〇SLM
SLMとは
SLMとはサービスレベルマネジメントの略で、システム運用に代表されるITサービスの提供者と利用者の間で目標値を設定・合意し、サービスの提供が適切に維持されるように行われる管理の事である。

サービス内容の数値化
ITサービスは形のある生産物ではないため、その品質は何らかの指標を用いて数値化しなければ目で見ることはできない。SLMでは管理すべき品質は必ず数値化しなければならず、逆に数値化できないものは品質として管理できないことに注意しなければならない。

サービスレベル要件の策定
何らかのITサービスを新規にはじめる際、そのサービスに期待する要件を数値としてあらわす必要がある。これをサービスレベル要件と呼び、主に利用者側が作成・提示する情報となる。

SLAの締結
サービスの利用者から提示されたサービスレベル要件を元に、サービスの提供者は提供するサービスの品質目標を利用者と協議し、その合意の結果を明文化する。これをSLAを呼び、以後のサービス提供における品質管理指標として扱われる。

定期的なモニタリング
SLAが締結されたら、その内容に従ってモニタリングを開始する必要がある。品質を数値として表すためにどのような方法でモニタリングを行うかもSLAによってあらかじめ合意しておく必要がある。

定期的なレビュー
一定期間、例えば月に一回の頻度でモニタリングの結果がSLAによって合意された品質を下回っていないことをサービスの利用者と提供者が揃ってレビューを行う事が推奨される。仮に品質が下回っている事が確認された場合、その改善策は双方が協議して決めることになる。

合意を重視する
サービスの品質は提供者側だけが関与するものではない。提供者が万全な体制を敷いていても利用者が無茶な使い方をすればSLAが達成できないケースもあり、サービス品質は双方の「合意」によって維持される必要がある。

たまに見直す
一度決めたSLAは不変なものではなく、時に見直しを行うこともある。最初は大雑把に決めた数値でも、モニタリングを続ければ正確な正常域が分かってきたりするので、やはりサービスの提供者と利用者の合意を元にSLAを更新することも重要である。

無茶な目標は設定しない
SLAは「合意」による双方向性を重視するため、あからさまに合意しがたい目標は設定すべきではない。例えばサービスに期待する品質を担保できない目標や過剰ともいえる品質目標は適切ではないため、やはり協議によって是正を試みる努力が必要となる。

〇サービスの継続的改善活動
サービスの継続的改善活動とは
サービスの継続的改善活動とは、システム運用などのITサービスの品質が時間と共に劣化することを防ぎ、常に一定以上の水準を維持できるようにするための活動である。

品質と目標は変わるもの
ITサービスの提供期間が長くなればなるほど、品質やその目標値は変化するものである。例えば提供者側の体制が劣化してサービスの品質が低下したり、逆にサービス自体が陳腐化して開始直後ほどの品質が求められなくなったりすることもある。

品質の測定
サービス品質を改善するためには、必ずそれが数値で測定できるものでなければならない。測定できなければ現象をとらえることが出来ず、現象をとらえることができなければそもそも管理すること自体が困難であるからだ。

KPIの取得
品質を測定して数値化したものを合わせて重要業績評価指標と呼び、KPIと略す。KPIはあくまで実績値でこれ自体が何らかの意味を持つわけではないが、例えばSLAで設定した目標と比較することで現在の品質がどの程度の水準にあるかを測ることができる。

PDCAサイクル
改善活動において「計画」「実施」「点検」「処置」という４つのフェーズを繰り返すことで品質を維持向上しようというのがPDCAサイクルである。計画が見当外れだとその後のフェーズ全てが的外れになる恐れがあるため、最初が肝心である。

費用対効果の検討
例えば無限に資金や時間があれば品質を上げ続けることは可能だが、現実としてそんなことは不可能である。限られた時間や予算の範囲内で出来ることをやり、時に出来ないことはできないと言う勇気も改善活動では必要である。それをやりたいならもっと予算下さい、とか。

オーナーが責任を持つ
サービスの継続的改善活動は部下や下っ端に指示してやらせればいいというものではなく、サービスの提供者と利用者の双方のオーナーが責任を持って進めなければだいたい失敗する。主体性、そして品質改善をするという合意がなされることで初めてその土壌が整うのである。

[No.14] 2017/10/26(Thu) 21:12:41
116-220-176-147.rev.home.ne.jp

Name

E-Mail

URL

Subject

> ※適宜更新中です
> 
> システム運用技術
> 〇システム運用技術の概要
> システム運用技術とは
> システム運用技術とは、コンピュータを利用した様々なシステムを使用するにあたり、安定してサービスを提供できるように理論や経験をもとに体系化されたノウハウ集である。
> 
> 絶対の指針ではない
> システム運用技術は机上の理論と過去の蓄積を組み合わせて作られたベストプラクティスであり、「こうすべき」という規定や指針ではない。それぞれの環境に合わせてカスタマイズすることで効果を発揮することになるだろう。
> 
> とはいえ安定稼働のためには必要
> コンピュータシステムの健全な利用のためにはセキュリティ対策一辺倒ではなく、日頃から適切な運用が行われて初めて安定して利用することができるのである。システム運用技術は日常的な安定稼働のために必要な技術として捉えられている。
> 
> 習得までにかかる年月
> システム運用技術の習得にはオーソドックスな理論と現実に存在するコンピュータシステムの知識、そして自身の経験をも要求する。基本的な技術力を前提として最低１年の机上での講習と２年間の実習、さらに３年間の実務を経て初めて身についたと言う事が出来る。
> 
> 〇システム監視と障害対応
> システム監視運用とは
> 監視運用とはコンピュータを使用したシステムや業務で異常が発生したことを素早く検知することを目的とした運用業務、及び仕組みのことである。
> 
> 障害対応とは
> 障害対応とは、システム監視によって検知された異常を回復する際に行われる対応である。本来的には両者は別の分類ではあるが、現場の業務では区別しづらい場面もあり、合わせて語られる事も多い。
> 
> 異常の種類
> 一口に異常と言ってもその種類は星の数ほどあり、無視していいものから即座に対応する必要があるものまで千差万別である。
> 
> 捉えたい異常をはっきりと定める
> 起きると困ったことになる『異常』とは何なのか、ということをはっきりと定めることが監視運用のスタートである。
> 
> 最初はある程度大雑把に決める
> とはいえ起こりうるすべての事象をあらかじめ予測して定義することは不可能なので、ある程度大雑把に『異常』の範囲を決め、実際に運用をしながら絞り込んでいくことがベターである。
> 
> 異常の重要度を決める
> 発生することが想定される異常の中には急いで対応すべきものや、重篤な影響が出る前に早めに知らせてほしいもの、とりあえず起きたことけ記録しておきたいものまである。そうした意図に従い、検知時に重要度をセットで通知することも重要である。
> 
> 過去の知見を活かす
> 同じようなシステム構成が他にあれば、その運用実績を生かして同じような監視設定を行うことで定義漏れを減らし品質を高めることも可能である。
> 
> 異常の発生を捉える
> 事前に定義した異常事態が発生したとき、それに気づけるようにするために監視用のソフトウェアを使用する。もしくは定期的に人が目で見に行く、というやり方もある。
> 
> 異常が起きたときの対応
> 異常が発生したときにどうすればいいか、という点もある程度事前に決めておく必要がある。回復手順が確立できるのであれば手順書や自動回復プログラムを、そうでない場合には詳しく調べられる人に連絡する、などである。
> 
> 異常発生時の連絡先
> 異常発生時の連絡先は、万が一連絡が付かなかった時のために複数人の連絡先を登録しておくケースが多い。深夜寝てる時に電話がかかってきても必ず起きられるとは限らないからだ。
> 
> 影響の確認
> 対応方法が確立されていないような異常が発生した場合、まずはそのシステムや業務が正常に動作しているかを確認する。停止していれば緊急性は何段階か上がるが、逆に正常であれば緊急性は低い、などと判断できる。
> 
> 事象の切り分け
> 発生した異常の内容や原因を調べながら、問題の発生した部分を切り分けていく作業がある。事前に決めた監視の種類によって見ただけですぐ分かる物から腰を据えて調べないと分からないものまである。
> 
> 過去の対応結果の確認
> 発生した異常と同じような事象が過去にも起きていたかを確認するのも異常の特定や対応に有効だ。もし同じ事象を過去にも対処していたことがあれば、その内容を参考に今回も対処することができるからだ。
> 
> 対応内容の記録
> 異常発生の連絡を受けてから対応完了までの間、やったことや調べたことはしっかりと記録する。進捗管理という面もあるが、将来似たような異常が起きたときに参考になるためだ。
> 
> ワークアラウンド
> 発生した異常の原因がつかめないまでも、とりあえず正常に動くようにできる方策をワークアラウンドと呼ぶ。しばらくは応急処置で時間を稼ぎつつ、根本的な対応を検討する時に使う。
> 
> 〇問題管理
> 問題管理とは
> 問題管理とは、システム監視によって検知された異常や、ユーザーからの問い合わせ等で発覚した異常など、システム稼働への影響度が大きい問題が解決するまでを管理する運用である。
> 
> なぜそんなことをするのか？
> システム運用の現場は意外と忙しく、発生した異常への解決がなあなあで済まされてしまったり、うっかり忘れてしまった結果同じ問題を起こしてしまう事がある。そういう事が起こらないよう、影響度の高い問題は確実に解決できるように管理する必要があるのだ。
> 
> 問題の記録
> 問題管理においては、問題の発生した日時や発生したシステム、影響度と影響を受けたユーザー、対応優先度、発生した問題の詳細情報や実施した対応、そして最終的な解決手段までが記録される。
> 
> 原因調査と特定
> ワークアラウンドで影響を回避できても、原因が解消できていなければ再発の可能性は常にある。問題管理においては、まずしっかりと調査して原因を特定する事になる。
> 
> 解決策のレビューと実行
> 問題の原因が特定でき、解決策の準備ができたら他者のレビューを受けた上で実際に実行する。技術的な見落としはもちろん、経営や業務へのインパクトを最小にするために、上位職層もレビューに参加することがある。
> 
> 問題のクローズ
> 解決策の実行が完了し、問題のトリガーとなる事象が発生しても問題が発生しないことが確認できれば問題管理上ではクローズとなる。検証が困難な場合には、一定期間の経過をもってクローズされる場合もある。
> 
> プロアクティブな問題解決
> 同じようなシステム環境が複数存在していれば、特定のシステムで発生した異常は他のシステムでも起きる可能性があると言える。原因を突き止めた上で、他に同じ問題を起こしうるシステムがあれば、それらに対しても未然に解決策を実行することも重要である。
> 
> 〇変更とリリース管理
> ニコイチで運用
> 元々は変更管理とリリース管理という別の枠組みだが、実業務では個別に運用することは少ないため合わせて「変更リリース管理」と呼ばれることもある。
> 
> 変更管理とは
> システム構成やオペレーション内容など、システムの利用と運用に関わるものの追加・修正・削除をコントロールすることを変更管理と呼ぶ。「実際に変更すること」は変更管理では管理しないことに注意。
> 
> 変更管理の対象
> システムによって提供される業務などのサービスに何らかの影響を与えうる変更は全て変更管理の対象となる。ただし、本当に全部管理すると作業量が爆発するので、影響度が低い、実施部門が異なる、などの明確な指針を立てて適用対象外にしたり管理を簡素化している。
> 
> 変更の要求
> 変更が必要となった段階で行われるのが変更の要求であり、その活動を記録するために専用のレコードが起票される。実運用ではワークフロー化されていることも多い。
> 
> 変更のアセスメント
> 変更を計画する際、その計画が目的に対して十分であるか、失敗時のインパクトやその対策が考えられているか、等が評価される。問題があれば計画は差し戻されるが、承認されればテストへと移ることになる。
> 
> 重視されるポイント
> 変更のアセスメントでは「誰が提起したのか」「変更によって発生する影響」「変更しないことによる影響」「他の代替策ではない理由」「変更時に必要となるシステム停止時間とその計画」「変更に必要なリソース」「失敗した時の切り戻しパターン」などが重要視される。
> 
> 変更内容のテスト
> 計画が承認された後で実際にテストが行われる。順番が逆かと思われるかもしれないが、未承認状態でテストした結果テスト環境がとんでもないことになった、とかだと目も当てられないので、こういう順番になっている。
> 
> テスト結果の評価と承認
> 実際に行ったテストが当初の目標を達成し、他に問題を起こさないことを確認・評価された所で、改めて本番環境に対して展開することが承認される。
> 
> 変更諮問委員会
> 変更諮問委員会とは、変更管理においてアセスメントを満たしているかをチェックする機構である。技術職のみならず管理職や規模によって経営層も参加することがある。
> 
> 定例会と臨時招聘
> 変更諮問委員会を構成するメンバーは基本的には固定化し、週１回などの頻度で定例開催すると効果的である。定例会に間に合わないような緊急の変更については一部メンバーだけ招聘して開催することもある。
> 
> リリース判定も兼ねる
> 変更やリリースの承認で何度も諮問委員会に諮るのは実運用としても大変なので、変更諮問委員会で変更管理とリリース管理を兼ねる場合もある。その際でも、計画やテスト等の各ステップでのチェックは有効に機能するよう仕組みやルールを作る必要がある。
> 
> リリース管理とは
> リリース管理とは、変更管理等で承認を受けたシステム構成要素の追加・変更・削除を問題なくリリースできるようコントロールすることを目的とする。実際の作業はこちらのリリース管理で面倒を見ることになる。
> 
> 管理の主な項目
> リリースを管理するにあたり、その作業がどのような規模で、どれくらいの重要度なのかを定義する。変更管理でも同じようなことをしているので基本的にはこれを引き継ぐが、実運用では障害対応の回復手順としてシステム変更を行ってしまうこともあり、事後承認という形で記録を残すこともある。
> 
> リリース計画と承認
> 本番環境へのリリースを行うにあたり、利用者をはじめとする関係者と作業日程を調整したうえで計画化し、その承認を得る必要がある。
> 
> リリースと正常性の確認
> 本番環境にリリースされた後はそれで終わりという訳ではなく、変な悪影響が出ていないかという点をしっかり確認する必要がある。それが終わって初めて変更とリリースは完了となる。
> 
> しくじった場合
> 事前の計画やレビューで潰したはずなのであってもらっては困るものの、実際のところリリースした変更が原因で別のトラブルが起こることはある。そういう時はアセスメントに従って事前準備されているであろう切り戻し手順に従って変更前の状態に復旧させなければならない
> 
> そして問題管理へ
> リリースでしくじって問題を起こしてしまった場合、改めて問題管理を起票して原因を特定しなければならない。再発防止に加えて、正しい変更手順を作り直すことでようやく変更管理、そしてリリース管理をやり直すことができるようになる。
> 
> 〇SLM
> SLMとは
> SLMとはサービスレベルマネジメントの略で、システム運用に代表されるITサービスの提供者と利用者の間で目標値を設定・合意し、サービスの提供が適切に維持されるように行われる管理の事である。
> 
> サービス内容の数値化
> ITサービスは形のある生産物ではないため、その品質は何らかの指標を用いて数値化しなければ目で見ることはできない。SLMでは管理すべき品質は必ず数値化しなければならず、逆に数値化できないものは品質として管理できないことに注意しなければならない。
> 
> サービスレベル要件の策定
> 何らかのITサービスを新規にはじめる際、そのサービスに期待する要件を数値としてあらわす必要がある。これをサービスレベル要件と呼び、主に利用者側が作成・提示する情報となる。
> 
> SLAの締結
> サービスの利用者から提示されたサービスレベル要件を元に、サービスの提供者は提供するサービスの品質目標を利用者と協議し、その合意の結果を明文化する。これをSLAを呼び、以後のサービス提供における品質管理指標として扱われる。
> 
> 定期的なモニタリング
> SLAが締結されたら、その内容に従ってモニタリングを開始する必要がある。品質を数値として表すためにどのような方法でモニタリングを行うかもSLAによってあらかじめ合意しておく必要がある。
> 
> 定期的なレビュー
> 一定期間、例えば月に一回の頻度でモニタリングの結果がSLAによって合意された品質を下回っていないことをサービスの利用者と提供者が揃ってレビューを行う事が推奨される。仮に品質が下回っている事が確認された場合、その改善策は双方が協議して決めることになる。
> 
> 合意を重視する
> サービスの品質は提供者側だけが関与するものではない。提供者が万全な体制を敷いていても利用者が無茶な使い方をすればSLAが達成できないケースもあり、サービス品質は双方の「合意」によって維持される必要がある。
> 
> たまに見直す
> 一度決めたSLAは不変なものではなく、時に見直しを行うこともある。最初は大雑把に決めた数値でも、モニタリングを続ければ正確な正常域が分かってきたりするので、やはりサービスの提供者と利用者の合意を元にSLAを更新することも重要である。
> 
> 無茶な目標は設定しない
> SLAは「合意」による双方向性を重視するため、あからさまに合意しがたい目標は設定すべきではない。例えばサービスに期待する品質を担保できない目標や過剰ともいえる品質目標は適切ではないため、やはり協議によって是正を試みる努力が必要となる。
> 
> 〇サービスの継続的改善活動
> サービスの継続的改善活動とは
> サービスの継続的改善活動とは、システム運用などのITサービスの品質が時間と共に劣化することを防ぎ、常に一定以上の水準を維持できるようにするための活動である。
> 
> 品質と目標は変わるもの
> ITサービスの提供期間が長くなればなるほど、品質やその目標値は変化するものである。例えば提供者側の体制が劣化してサービスの品質が低下したり、逆にサービス自体が陳腐化して開始直後ほどの品質が求められなくなったりすることもある。
> 
> 品質の測定
> サービス品質を改善するためには、必ずそれが数値で測定できるものでなければならない。測定できなければ現象をとらえることが出来ず、現象をとらえることができなければそもそも管理すること自体が困難であるからだ。
> 
> KPIの取得
> 品質を測定して数値化したものを合わせて重要業績評価指標と呼び、KPIと略す。KPIはあくまで実績値でこれ自体が何らかの意味を持つわけではないが、例えばSLAで設定した目標と比較することで現在の品質がどの程度の水準にあるかを測ることができる。
> 
> PDCAサイクル
> 改善活動において「計画」「実施」「点検」「処置」という４つのフェーズを繰り返すことで品質を維持向上しようというのがPDCAサイクルである。計画が見当外れだとその後のフェーズ全てが的外れになる恐れがあるため、最初が肝心である。
> 
> 費用対効果の検討
> 例えば無限に資金や時間があれば品質を上げ続けることは可能だが、現実としてそんなことは不可能である。限られた時間や予算の範囲内で出来ることをやり、時に出来ないことはできないと言う勇気も改善活動では必要である。それをやりたいならもっと予算下さい、とか。
> 
> オーナーが責任を持つ
> サービスの継続的改善活動は部下や下っ端に指示してやらせればいいというものではなく、サービスの提供者と利用者の双方のオーナーが責任を持って進めなければだいたい失敗する。主体性、そして品質改善をするという合意がなされることで初めてその土壌が整うのである。

Color ■ ■ ■ ■ ■ ■ ■ ■

Cookie / Pass