さて、今回は情報セキュリティ運用管理です。
早速ですが、心得帖です。
という事で、今回は僕的には中々の問題でした。
で、H22のPM1問題全て完了となります。
さて、次回ですが、そろそろPM2の研究序説という事で
色々と僕なりに考察を加えていこうかなと思う次第です。
まぁ、もちろんPM1も視野に入れながら、PM1,PM2の
纏め勉強ブログにしていけたらと思います。
でわ。
はじめに。 ■*こちらは題意考察編となります。■ このブログは我流・勝手気ままな高度情報処理試験における問題に対する題意を考察したり所感などを交えて、よくある解説や体験サイトではなく、面白おかしく?楽しみながら、まるで一緒に勉強してるようなブログになったらいいなと思い、(まぁそうはいっても勝手気ままなゆるい感じですが)開設しました。 なので僕の記録ですがジョーク程度の息抜きとなれば、幸いです。
広告
2014年8月17日日曜日
2014年7月26日土曜日
ITSM 心得帖・ITサービス継続性管理の心得。
さて、恒例の心得帖となります。
ITサービス継続性管理の心得です。
ITサービス継続性とくれば、計画に関する内容だという事で、障害時の対策となるのですが、
基本的に、事業継続性計画(BCP)や、ビジネスに影響するインパクト(BIA)とか、そういうものがキーワードで連想すると良いかもしれません。
災害を想定してどれだけの速さでサービス再開できるかを考えるプロセスとでもいいましょうか?
そういう意味では、AM2でよく出るキーワードとして、
災害時のサーバの状態はどうすべきかの指針があり、以下のものがあります。
ホットスタンバイ ⇒ ウォームスタンバイ ⇒ コールドスタンバイ ⇒ 相互協定
<優先度高>← →<優先度低>
で、
ホットスタンバイは、即時復旧なので、災害時即バックアップ切替となり、サーバクラスタなど同じ場所で切替実施で常にデータ同期されている状態。
ウォーム・・・は、ある一定期間の間で復旧とまぁ余裕があるので、災害時まではバックアップ側のデータは更新されていなかったり、不完全なものであるため、最新にしてから再開で良いので、バックアップ側は別場所にある。
あぁ、今回の問題はこれかな?
コールド・・・は、もう余裕あるので、障害後に事前にあらかじめ借りていたデータセンタとかでバックアップサーバ持ち込んで復旧させる方法。
相互に関しては、もう完全に2つサーバ持つ気なしで、同じのを他の会社間で貸し借りしてサービス回復するという物だそうです。
という事で、今回はまぁこんな感じです。
次回はセキュリティ関連問題で、よく出る感じでしかもちょっと難易度個人的に高し!かもしれないです。
まぁそのあたりはまず問題回答編でじっくりと考察してみる事にしますので、本ブログ題意解説編の再開はしばらくお待ちを、というか、問題回答編見て欲しいっす(苦笑)
ITサービス継続性管理の心得です。
ITサービス継続性とくれば、計画に関する内容だという事で、障害時の対策となるのですが、
基本的に、事業継続性計画(BCP)や、ビジネスに影響するインパクト(BIA)とか、そういうものがキーワードで連想すると良いかもしれません。
災害を想定してどれだけの速さでサービス再開できるかを考えるプロセスとでもいいましょうか?
そういう意味では、AM2でよく出るキーワードとして、
災害時のサーバの状態はどうすべきかの指針があり、以下のものがあります。
ホットスタンバイ ⇒ ウォームスタンバイ ⇒ コールドスタンバイ ⇒ 相互協定
<優先度高>← →<優先度低>
で、
ホットスタンバイは、即時復旧なので、災害時即バックアップ切替となり、サーバクラスタなど同じ場所で切替実施で常にデータ同期されている状態。
ウォーム・・・は、ある一定期間の間で復旧とまぁ余裕があるので、災害時まではバックアップ側のデータは更新されていなかったり、不完全なものであるため、最新にしてから再開で良いので、バックアップ側は別場所にある。
あぁ、今回の問題はこれかな?
コールド・・・は、もう余裕あるので、障害後に事前にあらかじめ借りていたデータセンタとかでバックアップサーバ持ち込んで復旧させる方法。
相互に関しては、もう完全に2つサーバ持つ気なしで、同じのを他の会社間で貸し借りしてサービス回復するという物だそうです。
という事で、今回はまぁこんな感じです。
次回はセキュリティ関連問題で、よく出る感じでしかもちょっと難易度個人的に高し!かもしれないです。
まぁそのあたりはまず問題回答編でじっくりと考察してみる事にしますので、本ブログ題意解説編の再開はしばらくお待ちを、というか、問題回答編見て欲しいっす(苦笑)
2014年7月17日木曜日
ITSM 心得帖・可用性管理の心得。
さて、問題のしめくくり、心得帖です。
今回は・・・可用性管理の心得です。
いつでも使える状態というのは、やはり安心するなぁと思います。
ユーザ視点という感覚であるのも特徴ですよね。
まさに、お客様は神様です(古っ!)
え~、次回、乞うご期待♪
2014年7月11日金曜日
ITSM 心得帖・サービスデスク管理の心得。
さて、今回の心得は、サービスデスクについての心得となります。
いつものように巻物にしたためて記録するでござる。

今回の問題で思ったのが、
やはりITILを意識した流れをイメージすべきであるなと思いました。
例えば、
サービスデスクで受け付けたインシデントは、
至急!サービス使える状態にすべく、解決・復旧を最優先
で頑張る。
①その場で回答可能だよといっても・・・
①-1:暫定的な対応(ワークアラウンド)による再発あるカモ的な一時解決
①-2:恒久的で再発はまぁないかな的な対応による恒久解決
②その場で回答不可能なのは、
各インシデント関連スペシャリスト方面にエスカレーション
③ ②での即答がダメな場合、①-1や、②による問題管理。
ただし、ここでは問題に対する原因究明だけ≪ここポイントやる。
・変更要求(RFC)
④問題管理で原因究明が終わったら、変更管理。
ここでは、以下を実施
・実装計画だけ
・影響有無(インパクト分析)←(あくまでも助言!)CAB/ECAB
⑤変更管理で承認が得られれば、リリース管理。
ここでは以下を実施
・リリース設計
・リリーステスト←ここで判明したインシデントなどをサポートデスクに報告!!
・他部署にアナウンス。周知徹底
・障害時の切戻し
・CMDBメンテ
・リリース実装
と、まぁこんな流れでインシデント発生~最高はリリース実装解決までとなるようです。
という事で、今回はここまで。
いつものように巻物にしたためて記録するでござる。

今回の問題で思ったのが、
やはりITILを意識した流れをイメージすべきであるなと思いました。
例えば、
サービスデスクで受け付けたインシデントは、
至急!サービス使える状態にすべく、解決・復旧を最優先
で頑張る。
①その場で回答可能だよといっても・・・
①-1:暫定的な対応(ワークアラウンド)による再発あるカモ的な一時解決
①-2:恒久的で再発はまぁないかな的な対応による恒久解決
②その場で回答不可能なのは、
各インシデント関連スペシャリスト方面にエスカレーション
③ ②での即答がダメな場合、①-1や、②による問題管理。
ただし、ここでは問題に対する原因究明だけ≪ここポイントやる。
・変更要求(RFC)
④問題管理で原因究明が終わったら、変更管理。
ここでは、以下を実施
・実装計画だけ
・影響有無(インパクト分析)←(あくまでも助言!)CAB/ECAB
⑤変更管理で承認が得られれば、リリース管理。
ここでは以下を実施
・リリース設計
・リリーステスト←ここで判明したインシデントなどをサポートデスクに報告!!
・他部署にアナウンス。周知徹底
・障害時の切戻し
・CMDBメンテ
・リリース実装
と、まぁこんな流れでインシデント発生~最高はリリース実装解決までとなるようです。
という事で、今回はここまで。
2014年7月1日火曜日
ITSM 心得帖・サービスレベル管理の心得。
ITSM 心得帖 2巻。という事で、ここに記録しておきます。
この心得帖を印刷して壁に貼るなり、枕に敷くなり(笑)、床の間に飾るなり・・・
まぁ魔除けには決してならないかもしれませんが(苦笑)
今回は、いやというほど、サービスレベルの達成しかないのかぃ!って感じでしたが、
まぁお客との合意した内容なんで、何が何でも死守してやるぞ~っていう位の心掛け
が、結果的に安心安全なサービス(システム)になるのかもしれません。
って、見たら、余白余ってしまったので、ちょっと落書きしてしまいましたが深い意味はないです。
次回からイメージは意味のあるものを目指すよう頑張ります。
(すいません)
という事で、、僕流・高度情報処理試験・勉強日誌~H25・ITSM(問題回答編)!!
でまた次回の問題から、武者修行?です(笑)。
題意考察はまたその時に。。。ですかねぇ。
今回はサービスレベル管理の心得です。
まぁ魔除けには決してならないかもしれませんが(苦笑)
今回は、いやというほど、サービスレベルの達成しかないのかぃ!って感じでしたが、
まぁお客との合意した内容なんで、何が何でも死守してやるぞ~っていう位の心掛け
が、結果的に安心安全なサービス(システム)になるのかもしれません。
って、見たら、余白余ってしまったので、ちょっと落書きしてしまいましたが深い意味はないです。
次回からイメージは意味のあるものを目指すよう頑張ります。
(すいません)
という事で、、僕流・高度情報処理試験・勉強日誌~H25・ITSM(問題回答編)!!
でまた次回の問題から、武者修行?です(笑)。
題意考察はまたその時に。。。ですかねぇ。
2014年6月21日土曜日
ITSM 心得帖・移行計画時の心得。
登録:
投稿 (Atom)
広告




