社内SEになりました

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

システム運用(可用性管理)

システム運用の可用性管理の説明です。

サービスレベル管理、キャパシティ管理ときて、今回は可用性管理。

そもそも何故これらを分ける必要があるのか、正直なところ、良くわかりません。

少なくとも私は実業務として分けて管理したことはありませんし、分ける必要性を感じたこともありません。

謎です・・・。

1.サービスレベル管理やキャパシティ管理との違い

サービスレベル管理は広く浅く、キャパシティ管理は狭く深く、可用性管理はその中間といったイメージです。

キャパシティ管理が上手くいかなければ、可用性が損なわれ、サービスレベルも低くなります。

でもキャパシティ管理だけきちんとすれば良いわけではなく、障害時の復旧手順の整備などを怠れば、可用性が低くなり、サービスレベルも低くなります。

同様にサービスデスクの対応が悪ければ、可用性に問題はなくても顧客満足度が下がりサービスレベル管理としては問題となります。

このように、管理する範囲(広さ)としては、キャパシティ管理<可用性管理<サービスレベル管理となります。

次に管理する大変さ(深さ)です。

キャパシティ管理は、やりだすとキリがないくらい、いろいろな管理項目があります。

CPU使用率、メモリー使用率、DISK使用率の管理は当然として、JAVAヒープの使用率やDBのフラグメント、さらにはアプリケーションのオンラインレスポンスなど、大規模でミッションクリティカルなシステムだと、さまざまな角度からシステムのリソース不足やその予兆がないか監視をしていきます。

キャパシティ管理を除いた可用性管理は、そこまでの大変さはなく、障害の分析がメインになり、どうすれば障害対応時間を短くできるか、とか、そういった管理になっていきます。

可用性管理を除いたサービスレベル管理になると、さらにできることは限られて、定期的に顧客に満足度調査をして、満足度を向上させるために何をすれば良いのかを考えたりしますが、できることはかなり限られます。

f:id:SystemEngineers:20210402212755p:plain

2.可用性管理の評価

可用性管理のプロセスの活動の成功度合いを評価するための主要なKPIの一番は、なんといっても稼働率です。

SLAではほぼ例外なく目標稼働率が設定されるので、その目標稼働率を達成できているかどうかが、可用性管理の評価の最重要指標となります。

他にもMTBF平均故障間隔)やMTBSI(平均サービス・インシデント間隔)、MTRS(平均サービス回復時間)といったマニアックな指標を用いたり、非可用性から生じるコストの削減率なんていう指標を用いたりすることもあります。

f:id:SystemEngineers:20210403184456p:plain

 【振り返り】

可用性管理の説明は以上で終了となります。次回はITサービス財務管理の説明をしていきたいと思います。

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

今週のお題「今年、学びたいこと」

はてなブログ今週のお題「今年、学びたいこと」

ペンスケッチ。

3ヶ月くらい前にInstagramデビューを果たし、いろいろな投稿を見ているうちにペンスケッチというものがあるのを知りました。

結構たくさんの人がやっていて、みんな上手い。

で、これだけ上手な人が多いなら、もしかしたら簡単なのかもしれないと・・・。

いろいろ調べてみると、ペンスケッチは鉛筆ではなくペンで描くのでペンスケッチと言うらしいです。(当たり前?)

そして、鉛筆で描くよりも「上手く見える!」そうです。

YouTubeでペンスケッチの描き方を見てみると、最初に描くものは、マグカップは難しいので、ネギがおすすめとのこと。

YouTube見てたら、もう上手くなった気がしてきました。

f:id:SystemEngineers:20210331203936j:plain

新入社員

4月1日なので、新入社員が入社しました。

グループ内の全会社の新入社員の自己紹介がフォーラムに掲載されます。

写真は履歴書のものを使ったのか、みんなかしこまった表情。

自己紹介のやる気に満ちたコメントを読んでいると、自分がひねくれて、薄汚れたように感じます。

文章を読んだだけで、そんな気になるので、対面で会ったら薄汚れた自分が恥ずかしくなって逃げ出すかもしれません。

IT部門にも新入社員を配属させて、私のような薄汚れた人たちに、新人オーラを浴びせれば、DXも大きく前進するかもしれません。

今週のお題「祝日なのに……」

はてなブログ今週のお題「祝日なのに……」

祝日って何ですか?

今まで2回転職をしました。1社目は小売のIT企業で土日祝日、年末年始は関係なく、休みは水土と木日のローテーション。入社数年間は元日さえ普通に出勤してました。

2社目は官公庁系のIT企業で、普通の民間企業よりも休みが多く、世間の人たちはこんなに休みがあったのかと驚愕してました。

そして3社目に再び小売業に戻り、祝日が関係なくなりました。

転職当初は休みが少ないと感じたものの、あっという間に慣れてしまいましたが、祝日が休みの人たちへの嫉妬は消えず、祝日が土曜日だったり天気が悪かったりすると、うれしくなります。

 日本から祝日が無くなればいいのにと思う今日この頃です。

f:id:SystemEngineers:20210320145946j:plain

LINEが・・・

LINEの中国問題。

LINE公式アカウントや顧客とのLINEビデオ通話の利用を当面の間、停止するようにとの通達が出ました。

幸か不幸かシステム部門ではLINEの管理をしていないので、直接、私の仕事には影響が出ませんが、それがITガバナンスとして良いのかどうか・・・

ちなみにzoomは有料なので(もう少し言えばシステム予算で契約しているので)、システム部門管轄です。

いろいろなデジタルツールがある中で、どこまでシステム部門で管理するべきか、これからますますグレーゾーンが増えそうです。

 

システム運用(キャパシティ管理)

システム運用のキャパシティ管理の説明です。

キャパシティ管理は、リソースの使用状況やパフォーマンスデータを定常的に監視し、リソース不足やパフォーマンス悪化の兆候を事前に捉え、問題が顕在化する前に対応をするプロセスです。

1.インフラやOSレイヤーでのキャパシティ管理

最低限、ネットワーク帯域やCPU、メモリー、DISK使用率などの定期的な監視が必要です。

これらが増加傾向にある場合、同じ傾向が続くと仮定したときにどれくらいでリソースが枯渇するかを予測し、増加を抑える対策がない場合には、リソース増強の計画を立てていきます。

またCPU待ち行列ページフォールト等は、定期的な監視まではする必要はないですが、レスポンス悪化等があった場合、原因調査ができるように情報取得はしておいた方が良いです。

f:id:SystemEngineers:20210319205421p:plain

2.ミドルウェアやアプリケーションレイヤーでのキャパシティ管理

実際のところ、CPUやメモリー、DISKの監視では手遅れになることが多いです。

これらの数字に影響が出る前に、ミドルウェアレイヤーやアプリケーションレイヤーの監視で問題を早期に潰していくことが重要です。

例えばメモリーです。JAVAのシステムではAPサーバーのプロセスがメモリーを確保して、プロセス内のスレッドで確保したメモリーを使う仕組みとなっています。

プロセスが確保するメモリーを増やす場合、オーバーヘッドが発生してレスポンスに影響が出るため、通常は搭載しているメモリーで使用できる最大値を初めから確保します。

例えば搭載しているメモリーが100GBで、APサーバーで60%まで使用してよい設計とした場合、APサーバーを起動した時点で60GBのメモリーを確保してしまうようにします。

実際のところは、APサーバーは60GB確保していても、OSが30GBしか割り当てていないような状態になったりしますが。

いずれにしても、本当のメモリー使用率を知るためには、APサーバー内のメモリー(ヒープ)使用率を確認する必要があります。60GBをフルで使っているのか、半分しか使っていないのか等は、APサーバーのGCログ等で確認することになります。

またミドルウェアには、リソースを利用する上限値を設定することができます。

例えばApacheのMaxClientsやTomcatのmaxThreadsなどの同時接続数の上限値です。

この上限に達してしまうと、CPUやメモリーに余裕があってもWebの応答は待たされることになり、レスポンス悪化の原因になります。

そのためミドルウェアの上限値を設定しているリソースも監視の対象となります。

f:id:SystemEngineers:20210319210332p:plain

アプリケーションの管理も重要です。

Webの応答時間は数値を取ることが難しいことが多いですが、最低限、バッチの処理時間は監視が必要でしょう。

f:id:SystemEngineers:20210319212002p:plain

3.大量にある項目で何を監視すれば良いか?

これらの項目を全て監視すると、それだけで物凄いコストが発生します。

毎月毎月、変化のない数値を見るのもモチベーションが下がりますし、大量にある情報の中で、重要な変化を見落とす可能性もあります。

CPUに負荷がかかりやすいシステム、JAVAヒープを大量に使用するシステム、DBの更新が激しいシステムなど、監視対象のシステムのリソース使用の特徴を掴み、リスクの低い項目は後から調査ができるように情報取得だけにして、定期的に監視をする項目を減らしていくことが重要です。

【振り返り】

キャパシティ管理の説明は以上で終了となります。次回は可用性管理の説明をしていきたいと思います。

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

今週のお題「〇〇からの卒業」

はてなブログ今週のお題「〇〇からの卒業」

物欲を卒業したのは20代後半の頃でした。

実家にいた頃は、けっこう物欲まみれで物に囲まれた生活をしていました。

一人暮らしをするようになって、2年に1回、引っ越しをしているうちに物が少なくなり、今でいうミニマリストになりました。

物がないと、その分、別のことに時間を割けるようになり、生活が豊かになる気がします。

そんなミニマリストの大先輩の私ですが、先月、突然母から実家にあるおもちゃを捨てるという連絡があり、慌ててレンタカーを借りて実家に行っておもちゃを回収。

物欲から卒業したはずが、どうやら再入学してしまったようです・・・。

f:id:SystemEngineers:20210313211916j:plain