社内SEになりました

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

今週のお題「私の好きなアイス」

はてなブログ今週のお題「私の好きなアイス」

母が大のアイス好きだったので、子どもの頃は毎日アイスを食べてました。

冷凍庫には常にアイスが常備。一日1つという決まりでしたが、こっそりと隠れて2つ食べ、弟に見つかって母に告げ口され、そしてケンカして・・・。

でも常備しているアイスは、30円のダブルソーダーとか、たまに奮発しても50円のアイスだけ。

うちは貧乏だからと言われ、100円のアイスなんて滅多に食べれず、「ラクトアイス」がアイスの最高峰だと思い、雲の上の存在のレディーボーデンにずっと憧れていました。

社会人になって一人暮らしをしても、アイスの100円の壁は厚く、自分の冷凍庫に常備しているアイスも6個入りの小さいヤツだけ。

今では150円とか200円とかのアイスも珍しくなくなったけど、それでも仕事で疲れたときに100円超えのアイスを買って食べると、自分がお金持ちになったような贅沢な気分に浸れます。

f:id:SystemEngineers:20200630114357j:plain

入社1年経過!

ここ3、4ヶ月はコロナのバタバタであっという間でしたが、今日で転職して丸一年が経ちました。

前職や前々職のIT企業から現職の事業会社に転職して、一番違うなあと感じたことは、作業実績を管理しないところです。

IT企業時代は、どのプロジェクトのどんな作業にどれくらいの時間を使ったか、毎日実績入力をしていましたが、現職では何もしていません。

IT企業時代は実績の管理をしていたので、自分や部下の生産性を管理することができましたが、今は残業が多くなければ、それでOKという超アバウト。生産性を測る指標なんて全くありません。

でも人間は楽な方にはすぐに順応してしまうようで、入社して感じた違和感も1、2ヶ月も経つと全く違和感を感じず、きっと今では生産性も落ちているんだろうなあと思います。

 

お中元

毎年、恩師にお中元とお歳暮を送っているのですが、コロナのドタバタですっかり忘れていて、慌ててネットで注文しました。

小売の会社に勤めたからには、当然、自社のECサイトです。

昨年の7月に入社したので、自社のECサイトで買うのは前回のお歳暮に続いて2回目。ログインをして、ふと注文履歴で前回のお歳暮を確認したところ・・・。送り先の「××先生」という送り先名が「××先生 様」!

ECサイトでは「様」しか選べないので、「様」以外を選ぶ場合には、備考にその旨を記載するようにヘルプが出ていたので、お歳暮の時にそのようにしたのですが、まさか「先生様」になるとは・・・。

ギフト担当の人が手作業で対応したのだと思うのですが、さすがに自社とはいえ「先生様」は許容しがたく、今回のお中元は他社のサイトで購入しました。

いくらパッケージとはいえ、「先生」くらい選べるようにして欲しいです。

今週のお題「お父さん」

はてなブログ今週のお題「お父さん」

父の日のプレゼントには、毎年頭を悩ませます。

下戸なので、父の日の王道のお酒とか、ぐい飲みとか、ビールグラスとか、そういったモノは全滅。さらに糖尿病なので、和菓子や洋菓子類も全滅。

金色のモノが好きなので、金色の草履とか、金色の鉄扇とか、金色のボールペンとか、金色のスプーンセットとか、しばらく金グッズをプレゼントしていたら、センスの悪いモノが増えていくことに耐えられなくなった母から、金グッズ禁止令が。

シャツやウエストポーチ、サングラス等の当たり障りの無いモノは一通りプレゼントしてしまっているので、ここ数年はステーキ肉ばかり。

そろそろ違うモノにしたいなあと思いながらも、父親の好みって良く考えると全然知らないなあと気づきました。

照れくさいけれど、父親の好みを確認するのが、父の日の一番のプレゼントなのかも、とふと思いました。

f:id:SystemEngineers:20200624214138j:plain

今年も肉

非機能要件(可用性)

非機能要件の中の可用性の説明です。

可用性とは、システムが停止することなく稼働し続ける能力のことで、稼働率で表すことができます。

ここでは、この可用性を要求定義や要件定義でどのように決めていくのかを説明していきます。

1.サービス提供時間

稼働率を決める前に、サービス提供時間を決める必要があります。

24時間提供なのか、1時間だけシステム停止をして23時間提供なのか、あるいは8時から22時などの日中帯だけの提供なのか、さらには土日祝日は終日停止して平日日中帯のみの提供なのか、といったことを決めます。

2.稼働率

どの程度のサービス停止に耐えられるのかを、ユーザー部門と合意します。

丸1日耐えられるのか、半日なら耐えられるのか、1時間なら耐えられるのか、といった障害1回に耐えられる時間と、年に1回なら許容できるか、月に1回でも許容できるか、といった頻度の2つの観点で、サービス停止許容時間を決めます。

そのサービス停止許容時間とサービス提供時間から稼働率が求められます。

その稼働率(目標稼働率)によって、システムの冗長構成が決まってきます。

以下のケース1の場合、目標稼働率が99.5%です。復旧作業に4時間かけられるので、コールドスタンバイかウォームスタンバイ程度の冗長構成で十分です。

f:id:SystemEngineers:20200621132655p:plain

以下のケース2の場合、目標稼働率が99.9%です。復旧作業に1時間しかかけられないので、冗長構成はホットスタンバイが必要となります。

f:id:SystemEngineers:20200621132803p:plain

以下のケース3の場合、目標稼働率が99.98%です。復旧作業にかけられる時間はケース2と同じですが、夜間であっても休日であっても1時間しかかけられないので、24時間体制で復旧できるオペレーターが常駐するか、そうでなければクラスタリングが必要となります。

f:id:SystemEngineers:20200621133208p:plain

またこの目標稼働率は、年間なのか月間なのかで大きく違います。

上記例は年間ですが、ケース1の目標稼働率99.5%でも、それが月間だった場合、休日であっても4.35時間での復旧が必要となり、ホットスタンバイ、あるいはクラスタリング構成が必要となります。

f:id:SystemEngineers:20200621134601p:plain

このように目標稼働率が同じでも、それが月間の場合には一般的に年間より1段階上の冗長構成が必要となります。

そして、これらがSLAやSLOの重要な指標となり、受入テストもこの時間を目安に合否判定することになります。

3.回復性

バックアップとその復旧について、RPO(目標復旧時点)とRTO(目標復旧時間)という指標で、どのレベルのバックアップ方式とするかを決めます。

そしてこのRTOは、受入テストでの合否判定の目安にもなります。

以下のケース1の場合、バックアップの対象がデータベースのデータだけであれば毎日深夜にデータをEXPORTすれば要件を満たすことができます。

f:id:SystemEngineers:20200621140945p:plain

以下のケース2の場合には、データベースの更新ログ等からの復旧が必要となるので、OracleであればRMANによるバックアップ等が必要となります。

f:id:SystemEngineers:20200621141129p:plain

またバックアップについては、何世代保持するかも決める必要があります。

バックアップデータは大容量となるため、世代数によって必要なDISK容量が大きく変わります。

サポート体制が365日であれば、バックアップの世代は3世代もあれば十分ですが、ゴールデンウィークや年末年始を休むような体制だと7〜10世代は必要となります。システムで障害を検知できるケースは、ゴールデンウィークや年末年始であっても速やかな復旧が可能ですが、ユーザーからの問合せで発覚する障害の場合、ヘルプデスクが休みだと営業日に初めて障害を認識するという事態が想定されるためです。

4.災害対策

大規模災害が発生し、データーセンターが倒壊や通信不能に陥った場合について、DR(Disaster Recovery)環境の有無を決めます。

大規模災害の場合、1週間から1ヶ月程度はデーターセンターが復旧できないと想定されるので、その間、業務運用で耐え凌ぐことができればDR環境を用意する必要はありません。逆に頑張っても数日レベルであればDR環境が必要となります。

DR環境を用意する場合には、RPO(目標復旧時点)とRTO(目標復旧時間)、RLO(目標復旧レベル)で、対策のレベルを決めます。

RPO(目標復旧時点)が発災時点であれば、リアルタイムに同期を取る仕組みが必要です。DR環境を用意する場合、通常はリアルタイム同期となります。

RTO(目標復旧時間)は復旧時間のスタートをいつにするかを明確にする必要があります。通常、DR環境への切り替えは人手で行うため、大規模災害では人命救助を優先させるため、切替判断には時間がかかります。常識的に考えれば、RTOは切替判断が出てからの復旧時間となりますが、それを明記しておかないとユーザー部門が勘違いする可能性があります。

例えばRTOが24時間の場合、ユーザー部門は1日だけ辛抱すれば良いと思ってしまいますが、実際には切替判断までに数日を要することが多いため、業務運用で凌ぐのは4、5日となります。ユーザー部門は大規模災害が発生すると、すぐにDR環境に切り替ると勘違いしているケースが多いので、注意が必要です。

RLO(目標復旧レベル)はバックアップの際にも用いることがありますが、通常のバックアップからの復旧は全面復旧なので、あまりRLOを使うことはありません。この指標は例えば復旧時に何らかの縮退運転を許容する場合に、例えば50%のユーザー数に耐えられるレベルまで復旧、バックアップオフィスでの業務再開まで復旧といった指定をします。

RLOはDR環境のスペックに影響します。50%の縮退運転が許容されるのであれば、CPIUやメモリーを削減することができます。

またDR環境を構築する場合、外部システムの制約を明らかにしておく必要があります。自分たちがDR環境に切り替っても、外部システムが切り替らない場合には、連携部分で制約が発生します。また外部システムもDR環境に切り替ったとしても、同じタイミングで切り替る保証がないため、その点も設計時に考慮が必要となります。

DR環境に切り替った後のことも決める必要があります。元の環境に戻す仕組みとするか、一方通行とするかで、前者は後者よりも費用がより多く発生します。

BCPをシステム部門主導で進めると、DR環境のことだけに目がいってしまいますが、人の命に関わるような社会インフラでない限り、DR環境無しで耐え凌ぐ方法を考える方が現実的です。

単純なシステム環境だけであれば、AWS等のクラウドを利用すれば比較的簡単に実現できますが、それを運用するシステム部員の作業環境は自分たちで用意しないといけません。ましてやオンプレの場合には、DR環境を構築する費用は膨大なものになります。

東日本大震災クラスでもDR環境は不要であったことを考えると、利用するかどうか分からないDR環境にお金をかけるよりも、その分の費用を災害が発生した場合の補填にすることを考える方が建設的だと思います。

【振り返り】

今回は可用性の説明でした。次回は性能の説明をしていきたいと思います。

①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ/アクセシビリティ
⑧システム環境

今週のお題「傘」

はてなブログ今週のお題「傘」

タマゴタケが超かわいいのです。

特に傘が開く前の子どもタマゴタケを道ばたで発見すると、四葉のクローバー以上に幸せ気分になれます。

生まれた時は白いタマゴ状態で、そのタマゴが割れて、中から超かわいいタマゴタケが顔を出します。その後、タマゴ形の傘のまま柄が伸びて、徐々に傘が開いていって大人のタマゴタケに成長します。

大人になると、もうかわいくありません。

真っ赤っかで、いかにも毒がありそうなタマゴタケですが、実はとても美味しいらしいのです。生でも食べられるので、私もいつか食べてみたいです。

f:id:SystemEngineers:20200613123102j:plain

タマゴタケLOVE

社内SEの業種?

社内SEになって、もうすぐ1年。

お小遣い稼ぎでアンケートモニターをやっているのですが、そこでアンケートに回答する際、まずは自分の年齢、性別、居住地、仕事の業種や職種などの基礎情報を回答します。

その時に迷うのが「業種」です。

果たして私はIT業界で働いているのか、小売業界で働いているのか。

どの業界かによって、アンケートを続けられるかが変わったり、次のアンケートに繋がるかが変わったりする場合があります。

業種と職種をセットで聞かれる場合であれば、小売業のシステムエンジニアという回答になりますし、「お勤めの企業の業種は?」と聞かれれば小売業と回答できます。

迷うのが「あなたのお仕事の業種は?」と聞かれた場合です。仕事はITだけど、業種は小売、ITなのか小売なのか回答に迷います。

さらに言うと「お勤めの企業の業種は?」という問いも、小売業という回答が正解とは分かりつつも、自分は本当に小売業の人間なのかと思うと、本質的には違う気もしてしまいます。

社内SEに限らず、経理とか人事の人たちも同じなのだろうと思うのですが、前職までがIT企業だっただけに、1年経とうとしている今でも自分の業種に迷いを感じてしまいます。