2017年04月20日

2017年04月19日のつぶやき






posted by Yamato Sakai at 09:01 | Comment(0) | TrackBack(0) | つぶやき | このブログの読者になる | 更新情報をチェックする

システム運用設計について(2-3) システム運用アーキテクチャ 問題管理、構成管理

さて、前回(システム運用設計について(2-2) システム運用アーキテクチャ インシデント管理・障害管理・セキュリティ管理)に引き続き、今回は下図の赤枠のうち、「4.問題管理」と「6.構成管理」について記述することにする。

it_operational_architecture.png

「5.変更管理」、「7.ライブラリ管理」、「8.リリース管理」について、これら3つの管理業務は密接に絡んでいるため、次回以降にまとめて記述する。

では、順を追って記述する。


4.問題管理

問題管理は、システムを運用するにあたり発生した問題について、恒久的な解決をするための業務である。

システムを運用するにあたり発生する問題とは、障害管理からエスカレーションされてきたものと、業務上の要件から発生するものや、システム運用上発生するものがある。

そして、問題の解決については、すでに発生した問題を事後的に解決するリアクティブ対応と、将来発生する可能性のある問題を事前に解決するプロアクティブ対応がある。

リアクティブ対応の例を挙げる。
例えば、障害が発生し、迅速な回復のために暫定的な対応を行ったとする。

しかし、そのまま放置すれば同じ障害が発生する恐れがある場合は、恒久的な対応を行い同じ障害が発生する恐れを取り除く、というものだ。

プロアクティブ対応の例を挙げる。
例えば、業務で使用しているサーバーの動作が遅くなったとしよう。遅くても正常に使えているのであれば、障害ではない。

しかし、これ以上遅くならないように、何らか障害が発生するまえにサーバーのスケールアップをする等の対応を行う、というものだ。


6.構成管理

構成管理とは、現在運用されているシステムの構成を管理する業務である。

例えば
・サーバーのハードウェア構成
・サーバーOS・ミドルウェアのバージョンやパラメーター
・ネットワーク機器の設定内容
・アプリケーションのバージョン
・クライアントOSのバージョンやパラメーター
など、運用しているシステムの現在の構成がどのようになっているかの情報を、一元的に管理するのである。

そして、運用しているシステムの構成が変更された場合は、直ちに情報を最新に書き換えて管理していく。

なぜ構成管理をする必要があるのだろうか。
例えば、サーバーOSのセキュリティパッチがリリースされたとしよう。

セキュリティパッチは、適用しない場合のリスクが重大な場合、迅速な適用が望まれる。

運用しているサーバーが、セキュリティパッチの適用対象かどうか、現在の構成を適切に管理していない場合は迅速な判断ができない。

従って、システムを安全に運用するためにも、適切な構成管理をする必要があるのだ。


では、次回以降で「5.変更管理」、「7.ライブラリ管理」、「8.リリース管理」について記述することにする。

システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年04月17日

2017年04月16日のつぶやき




posted by Yamato Sakai at 09:01 | Comment(0) | TrackBack(0) | つぶやき | このブログの読者になる | 更新情報をチェックする

システム運用設計について(2-2) システム運用アーキテクチャ インシデント管理・障害管理・セキュリティ管理

今回は、前回で説明したシステム運用設計アーキテクチャのうち、下図赤枠部分について論じて行くこととする。

it_operational_architecture.png


この赤枠部分の各運用業務は、システムのサービスレベルを維持、向上するための業務である。
要するに、日々のシステム運用の安定性を担保し、システムの品質を向上させるために必要な運用業務である。

では今回は、「1.インシデント管理」、「2.障害管理(障害回復)」、「3.セキュリティ管理」について記述する。


1.インシデント管理

まず、インシデントの説明をしよう。
よく、インシデントと障害は同じものと捉えがちだが、両者は異なるものである。

インシデントとは、システムの利用者が期待通りのことが出来ず、困っている状態のことである。
例えば、利用者がパソコンを使っていて、どこかのホームページを見ようとしたが見られない、としよう。
この場合、利用者は期待通りホームページを見られず困っている。
困っているだけなので、まだインシデントの状態であり、障害とはならない。

インシデントの原因を調べた結果、ブラウザに入力したURLが間違えていた場合、利用者に正しいURLを入力するよう依頼すれば、インシデントとして解決だ。

しかし、ルーターが故障していたとか、LANケーブルが切れていた、といった場合、このインシデントを解決するためには、取り除かなければならない問題が発生する。
このように、インシデントを解決するために、何らか取り除かなければならないことがある状態を障害という。

従って、インシデント管理とは、何らか困っている事象について管理をすることである。
そして、困っている状態の原因を調査し、解決するための切り分けを行い、障害と判断された場合に「2.障害管理」へとエスカレーションするための業務なのである。

インシデントは、利用者からの問い合わせやクレームなどにより発覚する場合と、システムに障害監視の仕組みを入れていた場合に上がってくるものがある。
両者とも、インシデントが障害なのかどうかの切り分けを、運用担当者により行う必要がある。
迅速な切り分けのためにも、切り分け表を整備する等の設計も必要である。


2.障害管理(障害回復)

障害管理とは、「1.インシデント管理」において、障害とされた事象についての管理を行う業務である。
管理については、障害そのものの対応状況を管理することと、ステークホルダーへの連絡や周知の管理をすることの両方が含まれる。

まず、障害そのものの対応状況の管理について記述する。
何よりも最優先すべきは、発生した障害によりシステムの稼働が停止または制限されている場合に、障害から回復させることを第一目的とすることである。
従って、運用設計においては、予想がつく障害の回復手順は整備しておく必要がある。

そして障害は、既知の障害と、未知の障害に分類される。
既知の障害とは、障害からの回復手順が判明している障害のことであり、未知の障害とは、回復手順が判明していない障害のことである。

既知の障害が発生した場合は、必要に応じてステークホルダーへの連絡や周知を行い、同時に回復手順により障害の回復を試みる必要がある。

また、未知の障害が発生した場合は、ステークホルダーへの連絡や周知に加え、保守部門への連絡を行い、調査や対応方法の確立の依頼をする。
障害の重大度によっては、緊急対策本部等を設置し、障害対応専門のチームを結成したほうがいい場合もある。
そして、一旦は暫定対応として、障害からの迅速な回復を試みる。
障害からの回復が完了すれば、「4.問題管理」へエスカレーションし、恒久的な対応策の検討、対応手順の確立を行う。

次に、ステークホルダーへの連絡や周知について記述する。
利用者にとって、システムが期待通りに動作しなければ、業務への影響が出てしまう。
従って、障害を検知した場合は、いち早く利用者へ周知する必要がある。

システムによりけりだが、例としては、まずは初報として、障害が発生していることを周知する。
その後、定期的に、障害からの回復状況と回復見込みを周知する。
最終的に障害から回復すれば、終報として回復が完了したことを周知する。
といった、利用者とのコミュニケーションが重要になる。


3.セキュリティ管理

セキュリティ管理とは、システムの安全性を確保するための技術的な対策と、何らかセキュリティインシデントが発生した場合の対応のことである。

まず、システムの安全性を確保するための技術的な対策について記述する。
システムの安全性を脅かす要素としては、外部からの脅威と、内部からの脅威に分けられる。

外部からの脅威とは、ハッカーによる攻撃や、災害などによる物理的な損害を受ける可能性のことである。
従って、攻撃から守るためのハードウェア・ミドルウェア・アプリケーション・ネットワーク各々のレベルでの対策を行う必要がある。
システムの予算やミッションクリティカル度合に応じて、対策を設計する必要がある。

内部からの脅威とは、利用者や保守担当者、運用担当者などのステークホルダーによる不正使用で損害を受ける可能性のことである。
従って、適切な権限管理や利用制限、いつ・誰が・どこから・何をしたか、といったログを残すことが必要である。

次に、セキュリティインシデントが発生した場合の対応について記述する。
セキュリティインシデントとは、外部から、もしくは内部からの脅威が実際に発生した状態である。
例えば、不正アクセスがなされ、システムで保持している情報が漏えいした場合が該当する。

セキュリティインシデントが発生した場合、それがシステムの障害によるものであれば、障害そのものは「2.障害管理」で管理する。
しかし、情報漏えいが発生した、といった場合は、漏えいしたことによる対応(調査や記者会見など)が必要になることがあるため、障害とは分けて専門のチームを設けて対応した方が良いだろう。
システムや運営会社の規模によっては、CSIRT(Computer Security Incident Response Team)の設置や、CISO(Chief Information Security Officer)の設置を検討した方が良い場合もある。


「4.問題管理」以降については、次回以降に記述する。

システム運用設計関連の記事一覧はこちらからどうぞ。
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 仕事のこと | このブログの読者になる | 更新情報をチェックする
2017年04月16日

泊まりで京都旅行するなら、大阪に泊まった方が良かった件

4月の始め頃に京都へ旅行したのだが、泊まりで行く場合に分かったことを書こうと思う。

京都にはホテルなどの宿泊施設が相当数あるのだが、予約のタイミングによっては全然空きがないというか、2人で1泊10万以上とかの部屋しか空いていないことが結構ある。
筆者は1か月前の3月始めにホテルを予約しようとしたのだが、全然空いていなかった。

まあ、世界に誇る観光地である京都なので、世界各国から観光客が来るだろうし、当然国内からも全国から観光客が来る。
だから、相当数の宿泊施設があっても、全然足りないということなのだろう。

で、筆者が考えたのは、日中は京都観光をして、泊まりは大阪にするのはどうか、という作戦だった。
京都と大阪は隣の街なので、移動時間もそんなにかからないし、大阪グルメも楽しみたかったので、京都と大阪一石二鳥作戦を検討してみた。

結果、大阪の方が圧倒的にホテルが空いていて、大阪グルメも堪能できた。

ということで、日中は京都観光、夜は大阪に泊まるという作戦の、参考情報を記述しておく。

まずは、京都市街と大阪市街の宿泊施設数を比較しておく。
(本稿執筆時点、じゃらんで大人2名1泊日付未定調べた数)

●京都市街の宿泊施設数
河原町・烏丸・大宮周辺 165件
京都駅周辺 174件
祇園・東山・北白川周辺 127件
合計:466件

●大阪市街の宿泊施設数
新大阪・江坂・十三・塚本 42件
大阪駅・梅田駅・福島・淀屋橋・本町 98件
大阪ベイエリア 23件
大阪城・京橋・市内東部 23件
心斎橋・なんば・四ツ橋 96件
上本町・天王寺・市内南部 47件
合計:329件

なんと、京都市街の方が100件以上も多いのに、大阪市街の方が空きが多かったのだ。
(あくまでも、筆者が3月上旬に、4月上旬の宿泊予約を入れようとした場合である)

では次に、京都と大阪間の移動について、記述しておく。
電車を利用した場合だ。
(本稿執筆時点)

●JR(京都駅→大阪駅)
新幹線を使う場合、新大阪駅で在来線に乗り換えて大阪駅まで移動する。
乗車券は京都駅から大阪駅まで560円、自由席特急券は京都駅から新大阪駅まで860円。
乗車時間は、京都駅から新大阪駅まで新幹線で約14分、新大阪駅から大阪駅まで在来線で約4分。

全て在来線を使った場合は、乗車券は京都駅から大阪駅まで560円。
乗車時間は、京都駅から大阪駅まで約28分。

●阪急(河原町駅→梅田駅)
特急を使うのが便利。特急料金は不要。
乗車券は400円、乗車時間は約44分。

●京阪(祇園四条駅→淀屋橋駅)
特急を使うのが便利。特急料金は不要。
乗車券は410円、乗車時間は、特急の場合は51分、快速特急の場合は45分。

と、京都市街から1時間かからずに、大阪市街へ移動できるのだ。
大阪駅と梅田駅は隣接していて、淀屋橋駅は梅田駅から地下鉄で1駅という位置関係だ。
心斎橋やなんば、天王寺といった繁華街へも地下鉄で十数分で行ける。

もちろん、京都でディナーをしてから、泊まるためだけに大阪へ移動するのも良いだろう。
京都のホテルが全然空いていない時のプランBとして、大阪泊もありだ、ということだ。
タグ:国内旅行
posted by Yamato Sakai at 16:28 | Comment(0) | TrackBack(0) | 旅行 | このブログの読者になる | 更新情報をチェックする
2017年04月15日

2017年04月14日のつぶやき






posted by Yamato Sakai at 09:01 | Comment(0) | TrackBack(0) | つぶやき | このブログの読者になる | 更新情報をチェックする
2017年04月14日

2017年04月13日のつぶやき


posted by Yamato Sakai at 09:01 | Comment(0) | TrackBack(0) | つぶやき | このブログの読者になる | 更新情報をチェックする
2017年04月13日

2017年04月12日のつぶやき


posted by Yamato Sakai at 09:01 | Comment(0) | TrackBack(0) | つぶやき | このブログの読者になる | 更新情報をチェックする

最高に旨い餃子の作り方

最高に旨い餃子が食いたくて、何度も試行錯誤を重ね、たどり着いたレシピをご紹介します。
餡にしっかり味をつけるため、冷めても旨いですよ。

●材料(60〜70個分)
白菜:1/8玉
にら:1/2束
豚挽き肉:約350g
餃子の皮:60〜70枚
にんにく:1〜2かけ
しょうが:にんにくと同量
ほたての缶詰:1缶

調味料
塩:適宜(文中で説明)
胡椒:小さじ1〜2杯
胡麻油:大さじ1杯
オイスターソース:大さじ1杯
鶏ガラスープのもと:大さじ1杯

焼くとき
油:適量
水:鉄板から3ミリくらいの量

つけだれ
醤油1:酢3+豆板醤 もしくは
酢+胡椒大量


●作り方
1.白菜をみじん切りにします。
DSC_1087.JPG
かなり多いかな、という見た目ですが、この大量の白菜を入れるのが旨くなる秘訣です。

2.みじん切りにした白菜に、塩を一掴み入れてよく混ぜておきます。
白菜の水分を絞るための工程です。
一掴みの塩=親指+人差し指+中指+薬指で塩をつかんだ量。

3.にらを小口切りにします。
DSC_1088.JPG


4.にんにくとしょうがをすり下ろし、きざんだにらの中に投入します。
DSC_1089.JPG


5.ほたての缶詰を開け、汁ごときざんだにらの中に投入します。
DSC_1090.JPG
ほたての身の部分だけ取りだし、細かく刻むのもOKです。
その方が、餡に馴染んで旨いです。

6.2.で塩と混ぜた白菜を両手で絞り、きざんだにらの中に投入します。
DSC_1091.JPG
きれいなふきんがあれば、ふきんで絞ると楽チンです。

7.豚挽き肉に塩をひとつまみ入れます。
DSC_1093.JPG
ひとつまみの塩=親指+人差し指+中指でつまんだ量

8.豚挽き肉をよく捏ねます。
DSC_1094.JPG
時間にして約3分、粘りけが出るまで捏ねます。

9.6.の豚挽き肉以外の材料と、塩ひとつまみ+塩以外の調味料を、捏ねた豚肉に投入し、よく混ぜます。
DSC_1095.JPG
捏ねる、というよりは、ざっくりと肉と野菜が馴染むように混ぜます。

10.9.の餡を餃子の皮でひたすら包みます。

11.焼きます。
ホットプレートでもフライパンでも良いのですが、まずよく熱してください。
油を引き、餃子を置きます。
しばらくすると、餃子の底面がきつね色になってきます。
水を鉄板から3ミリくらいになるまで入れ、すぐに蓋をします。(餃子にかけない)
水に少量の小麦粉を溶いて入れると、羽根つき餃子になります。
ジューっという音が乾いた音に変わったら、蓋を開けて餃子の間に油を少々たらします。
2分ほど置いたら、出来上がりです。
DSC_1352.JPG

簡単に作れるので、ぜひ試してみてください。
タグ:料理レシピ
posted by Yamato Sakai at 07:00 | Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする
2017年04月12日

2017年04月11日のつぶやき


posted by Yamato Sakai at 09:01 | Comment(0) | TrackBack(0) | つぶやき | このブログの読者になる | 更新情報をチェックする
※当ブログでは、ご質問、ご相談など、どんなお問い合わせでも受け付けています。 こちらの問い合わせフォームより、お問い合わせ下さい。 お問い合わせに関しては、当ブログ管理者だけが全て読んでおり、情報漏洩等無いよう厳重に管理しております。 -