社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

システム運用(問題管理)

システム運用の問題管理の説明です。

開発部門では、障害管理表や課題管理表で管理することが多いですが、運用部門ではそれらを問題管理表で管理します。

呼び方は違いますが、みんな同じものです。

1.問題とは

ユーザーがITサービスを使えない状態をインシデントと呼びます。そのインシデントの原因が問題です。問題を解決すれば、そのインシデントは二度と発生しなくなります。

問題管理で重要なことは、類似の問題を発生させないことです。

例えば、APサーバーがスローダウンするインシデントが発生したとします。一次対応として、APサーバーを再起動して復旧させました。

この対応だけだと、またスローダウンする可能性があります。

GCログを調べたところ、フルGCが頻発してCPU使用率100%の状態が続いていたために、スローダウンしたことが分かりました。

フルGCが頻発した原因を調べたところ、メモリーが1GBあるにも関わらず、Javaヒープの最大値が256KBであることが判明しました。ヒープサイズを初期値のまま拡張しなかったため、ヒープが枯渇してフルGCが頻発し、スローダウンに至ったことが分かりました。

このJavaヒープを500MBに拡張することで、スローダウンの発生を解消することができます。

では問題は、Javaヒープの設定が小さかったことでしょうか?

2.問題の追求はほどほどに

問題管理で重要なことは、類似の問題を発生させないことです。インシデントの直接の原因となっている問題を解消することは当然のこととして、潜在している問題を発見し、顕在化する前に対処することが、問題管理ではとても重要です。

顕在化した問題にだけ対処していては、いつまで経ってもシステムは安定稼働しません。

ただこの潜在している問題の追及は、ほどほどにしないとメンバーが疲弊してしまうので注意が必要です。

先の例の場合、ヒープザイズ以外に初期値のままの設定は他に無かったのでしょうか?ヒープサイズを拡張することで、他の箇所がボトルネックになって再び障害が発生する可能性があります。

問題を「ヒープサイズの設定が小さかった」ことではなく、「ミドルウェアのインストール時に初期値のまま設定のチューニングをしなかった」ことにすると、対策が変わり、解消できる問題の範囲も広がります。

では初期値の見直しをすれば安心でしょうか?

設定ミスがあったとしても、そもそも性能負荷テストをきちんとやってれば、その時点で問題が見つかっていた可能性があります。

では性能負荷テストのやり直しが必要でしょうか?

といった感じで、深堀すればするほど、どんどん対策が重たくなっていきます。

3.業務影響の度合いで臨機応変

すべての問題に対して、同じレベルで深堀していくと、メンバーも疲弊しますし、費用対効果の観点でも好ましくありません。

実運用では、業務影響の大きさによって、軽く流す問題、深堀をある程度で止めておく問題、徹底的に深堀して再発防止策を講じる問題など、バリエーションを持たせていくと限られたリソースを有効活用することができます。

属人的なやり方ではありますが、そもそもマニュアル化できるマネージメントの仕事なんて存在しません。常に判断し続けることがマネージメントの仕事なのです。

重要なことは、問題の深堀レベルを個人の思いの中だけでとどめず、メンバーと共有することです。なぜこの問題は軽く流していいのか、なぜそこまで徹底して再発防止策が必要なのか、そういった一つ一つの問題に対しての判断をメンバーと共有していくこと、可能であればディスカッションすること、それが一番深いレベルでの問題の対策なのではと思います。

【振り返り】

問題管理の説明は以上で終了となります。次回は構成管理の説明をしていきたいと思います。

①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理

 

今週のお題「#買って良かった2020」

はてなブログ今週のお題#買って良かった2020

父親の80歳の誕生日に旅行券をプレゼントしました。

父親は派手好きなので、リムジンの送迎付きのレストラン食事プランを推したのですが、母親が恥ずかしがると妹の猛反対にあい、無難な旅行券になってしまいました。

プレゼントした後コロナ感染が拡大して、危なく期限が切れるところでしたが、第一波と第二波の間に行けたようで、喜んでもらうことができました。

でもやっぱり私としては、リムジンが心残り。

コロナが落ち着いたら、リムジン送迎で一緒にレストランで食事できたらと思っています。

あれ?自分が乗りたいだけか???

f:id:SystemEngineers:20201220183540j:plain

ケチが災いしたトラブル

とあるシステムで顧客影響のあるトラブルが起きています。

ベンダー某社の動きが悪いので、システム子会社にセッティングしてもらって、直接、事情徴収をすることに。

某社の言い分は、うちで使っているシステムは15年前に作ったもので、言語はVB6、OSはWindowsXPなので、調査を進めづらいとのこと。原因が分かったとしても、マイクロソフトのサポートも切れているので、プログラムの改修は勘弁して欲しいとのこと。

ぐうの音も出ません。

とりあえず困っている状況を説明して、頑張って調査してくれるようにお願いしました。

中小企業でもないのに、今までどれだけシステム投資を抑えてきたのか・・・

業態・規模ごとに、必要なシステム投資の標準額のようなものが公開されるといいのですが。

 

今週のお題「もう一度見たいドラマ」

はてなブログ今週のお題「もう一度見たいドラマ」

金八先生が好きでした。

何となく教師を目指していたので、金八先生のような情熱を持った教師になりたいなと思いながらドラマを見ていました。

主題歌の「贈る言葉」も好きで、多感な年頃だったこともあり、何が悲しかったのか、一人で「贈る言葉」を歌っては、涙を流していた小恥ずかしい記憶もあります。

なぜ「贈る言葉」で泣いていたのか。

汚れてしまった今の自分には思い出せないけれど、もう一度金八先生を見たら、純粋だったあの頃の心を思い出せるでしょうか。

f:id:SystemEngineers:20201212203959j:plain

 

社内SEの接客

今年も繁忙期の応援で、売場で接客。

コロナ感染も拡大しているし、平日だし、お客さまも少ないかと思ったら、幸か不幸か忙しい。

しかもクリスマスや年末が近いので、いろいろ個別のご要望も多く、マニュアル通りにしか対応できない私には試練でした。

それでも幸か不幸か、客層が高齢の方が多いので、手際の悪い私でも、のんびりと待っていただけます。

改めて思うのは、システムの使い勝手が悪いこと。キチキチに費用対効果が出ないシステム投資を抑えた結果、目に見えないところで効率が悪くなっています。

何ごとも、ゆとりが大切です。

システム運用(インシデント管理)

システム運用のインシデント管理の説明です。

インシデント管理に限らず管理全般に言えることですが、何の目的で管理するのかを明確にすることが重要です。管理のための管理になってしまうと、管理される側のモチベーションが下がり、形骸化してしまいます。

1.インシデント管理の管理対象

インシデント管理は、通常、インシデント管理表と呼ばれるものを用いて管理をします。インシデント管理表に事象と対応内容を記載することで、次に同様のインシデントが発生した場合、速やかに同じ対応を実施することができるようになります。

例えば、ログにエラーメッセージが出た場合、インシデント管理表で該当のエラーメッセージを検索し、過去の対応内容を参照して同じ対応を実施する、といった感じです。

インシデント管理表には、「発生日/発見日」「発生時刻/発見時刻」「発見者」「分類」「インシデント内容」「業務影響」「対応状況」「対応者」「対応内容」「対応時間」「完了日時」といった項目があります。

ここで悩むのが「分類」、つまりインシデント管理の対象です。

インシデントとは、ユーザがITサービスを使えるべき時間に使えない状態のことをいいます。解決したい事象全てがインシデントとなるため、システムの停止やサービス品質の低下といった障害以外にも、パスワード忘れなどのユーザーに起因するものも、インシデントとなります。

つまり問合せも、インシデント管理の対象となるのです。

f:id:SystemEngineers:20201212133616p:plain

2.問合せをインシデント管理の対象とするか?

問合せは、問合せ管理表で管理することが多いかと思います。

インシデント管理表にも問合せを記載すると、二重管理となってしまいます。

教科書的には、問合せはインシデント管理の対象となりますが、実際の業務では対象とするべきでしょうか?

問合せをインシデント管理の対象とするかどうかは、インシデント管理の目的によります。

例えば全てのインシデントをヘルプデスクのような部署で一括で受付するような場合、インシデントの数と平均の対応時間等で、ヘルプデスクの人数を決めていくことになります。その場合、インシデントの内容が問合せであっても障害であっても、受付としては中身は関係なく、件数と対応時間、さらには応答率が重要になってきます。

このようにヘルプデスクのサービスレベルの向上(応答率の向上、対応時間の短縮等)を図るような場合、問合せだけ別の管理表にあるよりも、インシデント管理表に受付たすべてのインシデントが記載されている方が管理がしやすいです。

その場合でも問合せ管理表や問題管理表は必要となるので、インシデント管理からそれらの管理表に管理を移していくことになります。

f:id:SystemEngineers:20201212183732p:plain

逆に、ユーザー系IT企業でよくあるように、開発部門が保守も兼ねて問合せを受けているような場合、前述のような管理は行わないため、インシデント管理には問合せを含めません。ただし「問合せだと思っていたら障害事象だった」とか「障害だと思っていたら、ただのユーザーの操作ミス(問合せ扱い)だった」といったことがあるので、インシデント管理表と問合せ管理表は、多少、重複するものも出てきます。

f:id:SystemEngineers:20201212184536p:plain

このように、インシデント管理の対象を何にするかは、管理の目的によって異なるため、目的を明確にして管理することが無駄な作業をしないためにも重要となります。

3.インシデント管理と問題管理の違い

問題管理は、発生したインシデントの根本原因を解決するための管理です。

インシデントの根本原因を究明し、問題を解消することでインシデントの発生が無くなります。

それに対してインシデント管理の対象は、発生した個々のインシデントの一次対応までです。

例えば、サーバーがメモリー不足でスローダウンするインシデントが発生したとします。

サーバーを再起動してスローダウンが解消すれば、インシデント管理としてはクローズですが、同様のインシデントが再発する可能性は残っています。

モリー不足の原因を究明し、原因を解消すれば問題管理もクローズとなり、同様のインシデントは発生しなくなります。

インシデント管理は、インシデント発生の都度、記録をしていきます。同一事象であっても100回発生すれば、100件のインシデントとなります。

発生の都度、記録をする目的は、一次対応を漏れなく行うことと、対応の優先順位を決める判断材料とするためです。様々なインシデントが発生する場合、優先度の高いものから根本原因を究明し解決していくことになりますが、多発しているインシデントは対応の優先度が高くなります。

f:id:SystemEngineers:20201212193328p:plain

4.インシデント管理表は必要か?

これまでインシデント管理表の説明をしておきながら、必要か?は無いかもしれませんが、実はインシデント管理表は必ずしも必要なわけではありません。

インシデント管理表と問題管理表は重複する項目が多いためです。

インシデントの種類が多く(つまり問題管理の数が多い場合)、発生頻度も多い場合、インシデント管理表と問題管理表を分けて管理した方が管理がしやすいです。

でもインシデントの種類が少ない場合、分けて管理するメリットはありません。

問題管理表の中に、インシデント管理の要素を盛り込むことで、不必要な二重管理がなくなり効率的にインシデントと問題の管理が可能となります。

f:id:SystemEngineers:20201212193415p:plain

このように管理表というものは、管理する対象の種類や量によって、適切に表を分けたり統合したりすることが重要です。

【振り返り】

インシデント管理の説明は以上で終了となります。次回は問題管理の説明をしていきたいと思います。

①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理

 

今週のお題「自分にご褒美」

はてなブログ今週のお題「自分にご褒美」

20年勤めた会社を辞めたとき、自分へのご褒美に7泊8日のパラオ旅行に行ってきました。

なぜパラオなのか?

それは、タコクラゲと一緒に泳げるから。

20年間のご褒美がタコクラゲで良いのか?という葛藤と戦いながら、2月の有給消化中にパラオへ旅立ちました。

そしてジェリーフィッシュレイクへ。

大量のタコクラゲに囲まれて、最初は気持ち悪かったのですが、慣れるととてもかわいい。触るとツルツルしています。

とても充実した7泊8日のパラオ旅行でしたが、タコクラゲ。

1ヶ月近くの有給消化があったのに、20年の頑張りをタコクラゲにして、本当に良かったのだろうかと、いまだに自問自答しています。

f:id:SystemEngineers:20201206185546j:plain

タコクラゲ