勉強後記

千里の道も一歩から。学びから遊びまで継続活動の日記。

    スポンサードリンク

      このエントリーをはてなブックマークに追加 mixiチェック
    6.1 サービスオペレーションの概要
    サービスオペレーションの5つのプロセス→イベント管理、インシデント管理、問題管理、要求実現、アクセス管理
    イベント管理→サーバ、アプリケーションなどから通知されるすべてのイベントを監視し異常状態を通知するイベントが発生した場合、インシデント管理にエスカレーションする。
    インシデント管理→出来るだけ早くインシデントを取り除くことを目的に活動する。
    問題管理→問題の根本原因の特定、除去を目的とする活動を行うプロセス。
    要求実現→ユーザから要求される、リスクが少なく、低コストで発生頻度が多い作業をあらかじめ合意された手順に従って処理するプロセス。 
    アクセス管理→許可されたユーザにITサービスを使用する権限を付与し適切に使用されているかの確認などを行うプロセス。 
    サービスデスク→ITサービスプロバイダとユーザ間の接点となる組織。
    IT運用管理→ITインフラストラクチャを継続的に管理し、合意されたレベルでITサービスを提供するために日々の運用に責任を負う組織。
    技術管理→ITインフラストラクチャを継続的に運用・保守するために必要な技術やリソースを提供する組織。
    アプリケーション管理→運用中のアプリケーションの管理とサポートを担当する組織。 
    コミュニケーション→サービスオペレーションでの効果的なコミュニケーションによってすべてのチーム、部門がITサービスの提供やITインフラストラクチャの管理に関して標準的な活動が出来る。
    6.2 イベント管理
    イベント管理→ITインフラストラクチャ全体で発生するすべてのイベントをモニタリングするプロセス。
    イベント→構成アイテムやITサービス管理にとって重要性のある状態の変更のこと。通常、ITサービス、構成アイテム、イベント管理ツールなどによって生成される。
    情報のイベント→どのような対処も必要ないイベント。
    警告のイベント→サービスや装置がしきい値に近づいてきたとき生成されるイベント。
    例外のイベント→サービスや装置が正常に運用できていない状態で生成されるイベント。
    アラート→しきい値に達した時、変更があった時、または障害が発生した時の警告で、人に対して通知され、人の介入を必要とするもの。
    能動的モニタリングツール→デバイスやシステムなどの装置に問い合わせを行い、データを収集し、ステータスと可用性を判断するツール。
    受動的モニタリングツール→CI(構成アイテム)が一定の条件を満たすとイベントを生成して通知するツール。
    自動応答→発生したイベントの中で対処内容が明確で自動的に実行できるもののこと。
    アラート、人の介入→発生したイベントで人の介入が必要なアラートに対して人が対処を実施する対応のこと。
    エスカレーション→何らかの異常が発生していることを意味する例外はインシデント管理、問題管理、変更管理などいずれかのプロセスにエスカレーションする。
    6.3 インシデント管理
    インシデント管理→ITサービスに対する計画外の中断や品質の低下をインシデントとして管理するプロセスで発生時にはユーザに対する運用を可能な限り迅速に回復させる事に焦点をあてたプロセス。
    インシデント→ITサービスの計画外の停止や品質低下のことで将来的にITサービスに影響を及ぼす可能性がある生涯も含める。 
    サービスデスク経由でユーザから直接伝達された事象→「システムのレスポンスが悪くなった」「PCが故障した」といったユーザからの「問い合わせ」のことで、サービスデスクを経由してインシデントとして記録される事象のこと。
    イベント管理からのエスカレーション→イベント管理からインシデント管理にエスカレーションされてきた事象のこと。 
    技術スタッフによる記録→技術スタッフがハードウェア、ネットワークなどになんらかの不具合があることに気がついた時インシデントに記録しサービスデスクに問い合わせる。 
    インシデント・モデル→ 特定の種類の再発するインシデントを処理する手順を合意に基づいて事前に定義しておく方法のこと。項目として下記がある。
    ①インシデントを処理する手順
    ②処理手順に依存関係や共同処理がある場合、どのような順番で処理するかの時列の順序。
    ③責任(担当者、担当内容)。
    ④処理を完了するまでの期間、しきい値。
    ⑤エスカレーション手順(連絡先、連絡するタイミング)
    ⑥証拠保持の活動(エビデンスを残す活動)
    重大なインシデント→事業に深刻な影響を与える原因となるインシデントのこと。
    インパクト→インシデント、問題、変更におけるビジネスに与える影響の指標。サービスレベルが受ける影響の指標。サービスレベルが受ける影響の程度に基づくことが多い。下記5つの事を考慮して決定する。
    ①生命や健康に関わるリスク。
    ②影響を受けるサービスの数。
    ③財政上の損失。
    ④事業への評判への影響。
    ⑤規制上、法律上の違反。
    緊急度→インシデント、問題、変更が事業に顕著なインパクトを与えるまでに残された時間の指標。
    優先度→緊急度+インパクト。インシデント、問題、変更の相対的な重要度の識別に使用する。インパクトと緊急度をもとに決定し、解決し、解決時間目標の特定にも使用される。
    エスカレーション→インシデントをタイミングよく解決するための支援をする仕組み。
    機能的エスカレーション→サービスデスクのスタッフが単独でインシデントを解決できなかった場合か、初回解決の目標時間を超過した場合のいずれかが発生した時点で、インシデントをより専門的な知識を持つグループへ渡す事。
    階層的エスカレーション→重大なインシデントの場合はITマネージャに情報を提供する場合がある。
    1次サポートデスク→サービスデスク
    2次、3次サポートデスク→より多くの時間、あるいはリソースを所有しているサービスデスク以外の部門と専門家のサポートグループ。
    インシデント管理9つのプロセス→「識別」「記録」「分類」「優先度の決定」「初期診断」「エスカレーション」「調査と診断」「解決と復旧」「クローズ」
    インシデントの識別→インシデントはイベント管理プロセスからのエスカレーション、サービスデスクへの電話、webなどのセルフヘルプデスク、技術スタッフからのメールによって検出される。
    インシデントの記録→サービスデスクへ連絡されたもの、イベント管理ツールで自動検出されたイベントなどインシデントの受け取り方に関係なくすべてのインシデントの発生時刻、現象などを記録する事。
    インシデントの分類→発生したインシデントをハードウェアに関するもの、ソフトウェアに関するもの、捜査に関するもの等など様々な分類(カテゴリ化)する。そのごインシデントの優先度を決定する。
    初期診断→インシデントがサービスデスク経由で報告された場合、通常はユーザと電話している間にサービスオペレータが実行する。
    インシデントのエスカレーション→サービスデスクが単独で解決できなかった場合により高度な専門的知識を持つサポートグループに実施する行為。
    調査と診断→すでに明確になったワークアラウンドがない場合に必要となる。解決策が明確になった場合、解決策をテスト、適用、復旧させる。
    インシデントのクローズ→サービスデスクはインシデントが完全に解決されたことと、ユーザが満足しインシデントのクローズに合意していることを確認する。
    イベント管理のプロセス→イベント管理が管理するイベントがエスカレーションされてインシデントになる場合がある。
    問題管理のプロセス→問題管理のプロセスがインシデントの再発を防止するという意味でインシデント管理プロセスと関係がある。またインシデント管理プロセスから問題管理プロセス「問題」が報告される場合もある。
    サービス資産管理システムおよび構成管理システム(CMS)→インシデント管理プロセスが故障している装置を識別し、インシデントのインパクトを評価するために利用する。
    変更管理プロセス→変更が必要な場合、インシデント管理プロセスは変更要求を変更管理プロセスに提出して変更管理プロセスで処理を進める。
    キャパシティ管理→キャパシティ管理がパフォーマンスの問題を検知する場合がある。インシデント管理プロセスにワークアラウンドを提供する場合がある。
    可用性管理→可用性管理はインシデント管理プロセスで管理しているデータを利用してITサービスの可用性を判断し、インシデントライフサイクルで改善できる箇所がないか検討する。
    サービスレベル管理→サービスレベル管理はインシデント管理プロセスに対するサービスレベル(インシデントの応答時間、目標解決など)を合意する。
    6.4 要求実現
    要求実現→予期しないサービスの遅延や中断に起因するインシデントを取り除いた顧客やユーザからの要求を処理するプロセスをなんというか。
    サービス要求→情報や助言または標準的な変更やITサービスへのアクセスに対するユーザからの要求のことでサービスデスクで処理するもの。パスワードのリセット、新規のユーザ登録、アプリケーションのインストールなど。低リスク、発生頻度が高い、低コストという特徴がある。
    要求モデル→サービス要求を処理する、事前に定義した処理方法の事。
    セルフヘルプ→サービス要求、インシデントの登録やFAQの参照などユーザ自らサービスデスクを利用できる仕組みの事。
    セルフヘルプのITサービスプロバイダにとってのメリット→ITスタッフが不在でも24時間365日常時サービスを提供できるようになり、ITスタッフの削減、コストの削減、サービス時間の延長につながる。
    セルフヘルプデスクの事業部門にとってのメリット→Webインターフェイスであるため、ユーザはいつでもどこからでもサービスデスクを利用できるようになる。
    6.5 問題管理
    問題管理→イベント及びインシデントの根本原因を特定して解決するプロセス。将来発生する可能性があるインシデントおよび問題を防止し、インシデントが発生した場合迅速な診断し解決を可能にするための既知のエラー作成、ワークアラウンドの提供を実施する。
    問題→1つまたは複数のインシデントを引き起こす未知の原因。
    問題モデル→特定の種類の再発する問題を処理する手順を合意に基づいて事前に定義しておくこと。
    ワークアラウンド→完全な解決策がまだ存在しないインシデントや問題のインパクトを軽減排除すること、またはその方法の事。
    既知のエラー→診断に成功し、根本原因とワークアラウンドが識別、文書化された問題の事。
    既知のエラーデータベース(KEDB:Known Error Data Base)→すべての既知のエラーレコードを含むデータベース。下記2つを含む。
    ①サービスの回復や問題解決のために実施したワークアラウンド、解決策の詳細情報。
    ②障害内容、障害の兆候情報。
    リアクティブな問題管理→問題の根本原因を解決し、インシデントの再発を防止する問題管理。サービスオペレーションで実施される。下記10個の活動からなる。
    ①問題の検出。
    ②問題の記録。
    ③問題の分類(カテゴリ化)。
    ④問題の優先度の決定。
    ⑤問題の調査と診断。
    ⑥ワークアラウンドの特定。
    ⑦既知のエラーレコードの作成。
    ⑧問題の解決。
    ⑨問題のクローズ。
    ⑩重大な問題のレビュー。
    また下記4つの方法で検出される。
    ①サービスデスクからの報告。
    ②技術サポート・グループからの報告。
    ③イベント管理ツールからの通知。
    ④プロアクティブな問題管理の分析結果。
    プロアクティブな問題管理→将来発生しうるインシデントを事前に防止する問題管理。
    問題の記録→すべての問題において、問題に関連するあらゆる詳細情報を問題レコードに記録する事。
    問題の分類(カテゴリ化)→問題をハードウェアに関するもの、ソフトウェアに関するもの、操作に関するものなどに分類すること。
    問題の優先度の決定→インシデント管理と同じインパクトと緊急度から決定する。
    問題の調査と診断→既知のエラーデータベースを参照し過去に類似の問題がないか確認し、問題が過去にも発生している場合根本原因を特定する。 
    ワークアラウンド→問題によって引き起こされたインシデントに対して特定できるもの。
    既知のエラーレコード→診断が完了し、根本原因が特定できたら作成するもの。
    問題の解決→問題の根本原因取り除くために実施するもの。
    問題のクローズ→変更が完了し解決策が適用されたら実施する。
    重大な問題のレビュー→重大な問題に対してはレビューを実施、適切に実施された項目、されなかった項目、改善項目、再発防止法などを確認する。
    プロアクティブな問題管理→将来発生する可能性のある問題を予防すうる活動で通常は「サービスオペレーション」で開始されるが「継続的サービス改善」の一部として推進するものをなんというか。
    インシデント管理→問題によって引き起こされる場合が多くある問題管理のプロセスと関係のあるプロセス。
    サービス資産管理および構成管理→問題管理プロセスは、サービス資産管理および構成管理を使用して障害の発生している構成アイテムを識別し、問題解決のインパクトを判断する。
    変更管理→問題管理プロセスは問題を解決するために変更要求(RFC)を変更管理に提出する。
    リリース管理および展開管理→問題に起因してシステム変更が発生する場合、リリース管理および展開管理が変更を稼働環境に投入する責任を負う。
    可用性管理→停止時間を減少させ稼働時間を増加させる方法を特定する事に関与する。
    キャパシティ管理→パフォーマンスに関する問題の一部はキャパシティ管理による調査が必要となる。
    ITサービス継続性管理→重大な問題がいつまでも解決されないと、ビジネスが深刻なインパクトを受け始める。この場合ITサービス継続性管理がトリガーとなり、サービス継続性計画が発動される。
    サービスレベル管理→問題の発生が顧客と同意したサービスレベルに影響を与えるプロセス。
    6.6 アクセス管理
    アクセス管理→ユーザにサービスを使用できる権利を与える事が出来るプロセスでデータや知的所有権の気密性、可用性、完全性の確保につながるプロセス。
    アクセス→ユーザが利用する資格を持つサービスや機能やデータレベル/範囲のこと。
    ID→ユーザを個人として識別する情報で、ユーザごとに1意なものこと。
    権限→サービスや サービス群へのアクセスをユーザに提供する実際の設定のことで、一般的には読み取り、書き込み、実行、変更、削除などがある。
    サービス群→複数のサービスをグループ化したもので、利用可能な複数のサービスへのアクセスをユーザやユーザグループに付与する事で効率化を図ることができるもの。 
    ディレクトリ・サービス→アクセス権限を管理するためのツール。
    6.7 サービス・デスク
    サービスデスク→さまざまなインシデントやイベント処理に責任を負う専任のスタッフで構成される組織のことでITサービスプロバイダとユーザ間における日常の窓口の事。
    単一窓口(SPOC:Single Point of Contact)→事業部門から見たIT・サービスプロバイダへの単一の連絡手段。
    IT組織の全体の調整→円滑なコミュニケーションを維持しつつユーザの利益になるように、ITサービスプロバイダを調整する事。 
    フォローザサン→24時間365日サービスを提供するために世界中のサービスデスク、サポートグループを活用する事。 
    インシデントのオーナーシップ→受け付けたインシデントに対してクローズするまでインシデントを追跡し、必要に応じてフォローを行う事。
    ユーザおよびITスタッフとのコミュニケーション→インシデントを円滑に解決に導くためにユーザーや必要な部門と接点を持つこと。 
    進捗情報の提供→調査に時間を要するインシデントなどに対してユーザに途中経過などを報告すること。
    6.8 技術管理
    技術管理→技術的な専門能力とITインフラストラクチャの管理を提供する組織(グループ、部門、チーム)を目指す。
    ITインフラストラクチャ設計→対障害弾力性(障害に陥りにくい設計にする。障害が発生しても早く回復できる)や費用対効果の優れたITインフラストラクチャの設計の事。
    ITインフラストラクチャの保守→ITインフラストラクチャを最適な状態に維持するための技術力を提供する事。
    障害発生時のサポート→発生する技術的な障害を調査し解決する技術力を提供する事。 
    6.9 アプリケーション管理
    アプリケーション管理→アプリケーションのライフサイクル(要件の収集、設計、構築、展開、運用、最適化)を通して、アプリケーションの管理に責任を負い、運用中のアプリケーションの管理とサポートを担当する組織。
    ①アプリケーションの設計、機能
    ②機能の可用性の保証
    ③アプリケーションの保守
    ④障害発生時のサポート
    6.10 IT運用管理
    IT運用管理→ 事業部門に合意されたレベルでITサービスを確実に提供するために組織のITインフラストラクチャの継続的な管理と保守に責任を負う組織(グループ、部門、チーム)。運用コントロールと施設管理が含まれる。
    運用コントロール→ITインフラストラクチャの日常的な運用活動を実施したり、イベントを監視する。一般に運用統制室からITサービス、ITインフラストラクチャをネットワーク運用センターからネットワークを集中的に監視、管理すること。 
    施設管理→物理的なIT環境を管理し、電力や冷房設備を含めコンピュータ室、データセンター、復旧拠点を管理すること。

      このエントリーをはてなブックマークに追加 mixiチェック
    カードがダブついてきたのでスキルを追加して遊んでます。
    特安くなりましたねぇ・・・。売れないなぁ。

     まずは豪傑武将パックで手に入れた佐々さん処分。鉄砲防御にとも考えたのですがスキルがおいしすぎなので合成行きへ。

    sukirutuika008JPG
    欲しいのは三段撃ち神速のみ・・・。
    sukirutuika009JPG
    はい失敗。

    つぎ、ダブった義弘さんを鉄砲防御に・・・。(島津LOVEなので売りません。ていうか売れないよね極)
    sukirutuika010JPG
    よし成功。
    sukirutuika011JPG
    後は運用術つければOKかな。ていうか武吉高いね・・・。

    余った家久さんも合成へ。もう売れないのよ・・・。 
     sukirutuika012JPG
    成功したけど鉄砲隊剛撃・・・。まぁ円陣つかなかっただけ良しとしよう。

    もう1枚家久あるので慶次に合成。
    sukirutuika014JPG
    ぼちっとな。

    あっつ成功した。
    sukirutuika015JPG

    まぁ将来的には鉄砲騎馬で使うからよしとしよう。課金で天引くのが先か、銅銭貯めるて買うのが先になるか。
    はてさてどうなることやら・・・。

      このエントリーをはてなブックマークに追加 mixiチェック
    生贄ゲッツしたのでみんな大好きHさん事、 宝蔵院胤栄先制もランクアップします。
    lankup合成13JPG

    追加スロットはもちろん脇坂さんです。
    lankup合成14JPG

    ではいつも通りドキドキしながらぽちっとな。
    lankup合成15JPG
    なんとか成功したぜい。これで4枚ランクアップ済みになったなぁ・・・。

    最近IXAをどうするかで迷い中。どの道をいっても頂きが高すぎるw。
     

    このページのトップヘ