ネットワークの運用監視のお話。
一応、こちらで一通りの流れは説明済み。
よって、今回は勤務時間について。
3勤交代と2勤交代の話でも。
先に結論を言うと2勤はありえないので
できれば避けましょうっていうだけのお話です。
会社の常識は社会の常識ではありません。
これがネットワークエンジニアの仕事だといっちゃってる
業界であるという点には注意。
まず、24時間365日対応のネットワークであれば夜勤が発生。
人一人が24時間働くわけにはいかないので交代制になる。
で、夜をまたぐ人が朝までいるのか昼までいるのかによって
3勤と2勤の交代制にわかれる。
3勤なら朝の人、夕方の人、夜勤の人の3パターンにわかれる。
私のところはこの体制。
普通ですね。
2勤は実感したことないのですが、夜中交代はないはずなので
朝から夜と夜から朝のパターンにしぼられると思います。
で、こちらはめちゃきついです。
というか、ありえない勤務体系だと思ったほうがいいです。
でも、このパターンで仕事してるよって話をチラホラ耳にします。
で、これに加えてチームを組みますがその人数もまちまち。
また、連続勤務が何日あるの?とか、チーム数は?とか
その割り振りによっては忙しさは変化します。
私のところは普通の3勤交代パターン。
3日連続で働いて2日休み。
また、3日連続で働いて2日休みという勤務です。
連続している人は同じ時間帯で勤務します。
朝朝朝とか夜夜夜とか。
だから、一週間視点だと
2日休んで3日働いてまた2日休んでの一週間に見えます。
なんだ、楽じゃないかーなんてなりそうですが、そうでもないです。
まず、夜勤明けが休みとして割り当てられているわけですが、
3日連続夜勤となれば、体調を整えるのも大変です。
気がついたら1日中寝てたとかつぶれたとかなりがちです。
少々、時間がもったないですね。
あとは、そもそも夜勤に絶えれない人は
この時点でいやるになると思います。
このあたりがデメリット。
でも、夕方働くなら朝が空いてるとか
朝に働くなら夕方自由とか通勤ラッシュにまきこまれないとか
平日休みが発生で街も空いてるとか人と違う時間を過ごせます。
それをメリットととるならありでしょう。
また、3勤でわかるように24時間を3人で割るので1日8時間。
つまり、残業はほとんどないというわけです。
パターンはいろいろ。
普通なら
休休 朝朝朝 休休 夜夜夜 休休
って感じでしょうけど
変則だと
休 夜夜夜夜夜 休休休 朝夕 休
といったパターンもあるのかもしれません。
ちなみに、このサイクルを効率よくまわすのであれば、
チーム数を増やせばいいだけですね。
もちろん、チームあたりの人数もチーム数も工数依存ですが、
そんなに大量に人がいるってわけでもないものです。
いろんな案件の情報なり規模を見たり聞いたりしましたが、
1チーム5人未満が相場だと思います。
大きなネットワークでも全体で10人いるかな?って感じですね。
規模が大きいと役割をわけるってのはあります。
コールセンターやヘルプデスク化するとか
1次保守という立場なのか2次保守という立場なのか
1次保守と連絡する立場なのかといろいろです。
でも、今回は基本保守の話なのでそのつもりで説明します。
で、ここまで話をして想像がつくと思うのですが
この状況で2勤ってどうなのよということです。
まず、24時間を2人で割って一人12時間ですよね。
そして、夜勤が発生した場合は1日の半分を仕事でとられて
かつ睡眠時間を気にしなければいけないわけです。
すでにこの時点でありえないですね。
休みをうまく当てはめてくれないスケジュールであれば
寝たり起きたりの繰り返しになってしまう恐れがあります。
この時点で体調壊しそうですね。
基本、夜働くってのはやっぱりありえないです。
でも、何かあるから夜働くわけです。
何かってのはシステム障害です。
たった一つの障害のために人が起きなければなりません。
もちろん、障害の緊急度に強弱はありますが、
システムによっては新聞沙汰レベルとなる強があるわけです。
発生確率でいえば低いですし、もしも、たらればの世界です。
でも、そのもしもに備えるために運用監視が必要です。
システムの稼働率が99.999%だっとしても100%にはならない。
だから、誰かが見る。
でも、どうせ見るなら極力忙しくない状況をつくるべきです。
それができれば、いいシステムとなります。
たとえば、障害があっても二重化により影響度がない
もしくは少ないといった状況をつくりだせばOKです。
こういったシステムを用意できれば
夜何かあっても夜の間に対応をする、ではなく、
朝一にゆっくり慎重に対応すればいいわけです。
片っ端から寝ている人を起こして顧客やSE・NEに連絡して
なんとかしてくれーって知らせる仕事がメインじゃありません。
サーバのバックアップやネットワーク機器の体調管理をするのが
本来の運用監視の仕事です。
夜勤の人がしんどい思いをしなくていいのが理想です。
こうやって見えてくるのがシステムを保守する手前までに
品質のよいシステムができあがっているのかってことですね。
設計や構築のツケを運用監視にまわした分だけ大変です。
運用監視が崩壊した案件なんてのも噂で聞きます。
そして、案件型のネットワーク上流下流の世界では
運用監視は軽視しがちなところがあります。
まわりまわって2勤なんてことがあるのでしょうと想像します。
ただ、私が思う本当の理想系は構築した人が運用監視をして
システムの面倒を見続けるインフラエンジニアってのが
必要なんじゃないかと思いますし私はそれを目指したいです。
一応、こちらで一通りの流れは説明済み。
よって、今回は勤務時間について。
3勤交代と2勤交代の話でも。
先に結論を言うと2勤はありえないので
できれば避けましょうっていうだけのお話です。
会社の常識は社会の常識ではありません。
これがネットワークエンジニアの仕事だといっちゃってる
業界であるという点には注意。
まず、24時間365日対応のネットワークであれば夜勤が発生。
人一人が24時間働くわけにはいかないので交代制になる。
で、夜をまたぐ人が朝までいるのか昼までいるのかによって
3勤と2勤の交代制にわかれる。
3勤なら朝の人、夕方の人、夜勤の人の3パターンにわかれる。
私のところはこの体制。
普通ですね。
2勤は実感したことないのですが、夜中交代はないはずなので
朝から夜と夜から朝のパターンにしぼられると思います。
で、こちらはめちゃきついです。
というか、ありえない勤務体系だと思ったほうがいいです。
でも、このパターンで仕事してるよって話をチラホラ耳にします。
で、これに加えてチームを組みますがその人数もまちまち。
また、連続勤務が何日あるの?とか、チーム数は?とか
その割り振りによっては忙しさは変化します。
私のところは普通の3勤交代パターン。
3日連続で働いて2日休み。
また、3日連続で働いて2日休みという勤務です。
連続している人は同じ時間帯で勤務します。
朝朝朝とか夜夜夜とか。
だから、一週間視点だと
2日休んで3日働いてまた2日休んでの一週間に見えます。
なんだ、楽じゃないかーなんてなりそうですが、そうでもないです。
まず、夜勤明けが休みとして割り当てられているわけですが、
3日連続夜勤となれば、体調を整えるのも大変です。
気がついたら1日中寝てたとかつぶれたとかなりがちです。
少々、時間がもったないですね。
あとは、そもそも夜勤に絶えれない人は
この時点でいやるになると思います。
このあたりがデメリット。
でも、夕方働くなら朝が空いてるとか
朝に働くなら夕方自由とか通勤ラッシュにまきこまれないとか
平日休みが発生で街も空いてるとか人と違う時間を過ごせます。
それをメリットととるならありでしょう。
また、3勤でわかるように24時間を3人で割るので1日8時間。
つまり、残業はほとんどないというわけです。
パターンはいろいろ。
普通なら
休休 朝朝朝 休休 夜夜夜 休休
って感じでしょうけど
変則だと
休 夜夜夜夜夜 休休休 朝夕 休
といったパターンもあるのかもしれません。
ちなみに、このサイクルを効率よくまわすのであれば、
チーム数を増やせばいいだけですね。
もちろん、チームあたりの人数もチーム数も工数依存ですが、
そんなに大量に人がいるってわけでもないものです。
いろんな案件の情報なり規模を見たり聞いたりしましたが、
1チーム5人未満が相場だと思います。
大きなネットワークでも全体で10人いるかな?って感じですね。
規模が大きいと役割をわけるってのはあります。
コールセンターやヘルプデスク化するとか
1次保守という立場なのか2次保守という立場なのか
1次保守と連絡する立場なのかといろいろです。
でも、今回は基本保守の話なのでそのつもりで説明します。
で、ここまで話をして想像がつくと思うのですが
この状況で2勤ってどうなのよということです。
まず、24時間を2人で割って一人12時間ですよね。
そして、夜勤が発生した場合は1日の半分を仕事でとられて
かつ睡眠時間を気にしなければいけないわけです。
すでにこの時点でありえないですね。
休みをうまく当てはめてくれないスケジュールであれば
寝たり起きたりの繰り返しになってしまう恐れがあります。
この時点で体調壊しそうですね。
基本、夜働くってのはやっぱりありえないです。
でも、何かあるから夜働くわけです。
何かってのはシステム障害です。
たった一つの障害のために人が起きなければなりません。
もちろん、障害の緊急度に強弱はありますが、
システムによっては新聞沙汰レベルとなる強があるわけです。
発生確率でいえば低いですし、もしも、たらればの世界です。
でも、そのもしもに備えるために運用監視が必要です。
システムの稼働率が99.999%だっとしても100%にはならない。
だから、誰かが見る。
でも、どうせ見るなら極力忙しくない状況をつくるべきです。
それができれば、いいシステムとなります。
たとえば、障害があっても二重化により影響度がない
もしくは少ないといった状況をつくりだせばOKです。
こういったシステムを用意できれば
夜何かあっても夜の間に対応をする、ではなく、
朝一にゆっくり慎重に対応すればいいわけです。
片っ端から寝ている人を起こして顧客やSE・NEに連絡して
なんとかしてくれーって知らせる仕事がメインじゃありません。
サーバのバックアップやネットワーク機器の体調管理をするのが
本来の運用監視の仕事です。
夜勤の人がしんどい思いをしなくていいのが理想です。
こうやって見えてくるのがシステムを保守する手前までに
品質のよいシステムができあがっているのかってことですね。
設計や構築のツケを運用監視にまわした分だけ大変です。
運用監視が崩壊した案件なんてのも噂で聞きます。
そして、案件型のネットワーク上流下流の世界では
運用監視は軽視しがちなところがあります。
まわりまわって2勤なんてことがあるのでしょうと想像します。
ただ、私が思う本当の理想系は構築した人が運用監視をして
システムの面倒を見続けるインフラエンジニアってのが
必要なんじゃないかと思いますし私はそれを目指したいです。
コメント
コメント一覧 (7)
私のところは、2交代で日勤は9:30から18:30。夜勤は17:00〜翌日10時までとなりまして、二日分働くことになります。休憩は、行ったらすぐの食事休憩と12時から何も無ければ2時間ずつ交代で仮眠します。
これから夏休みになってくるので、不足人員を補うために早出や残り勤務が発生します。早出は13時〜翌日10時、残りは17時〜翌日13時。障害さえなければ、非常に余裕のあります。障害発生すれば、それはお祭りですが一次対応なので関係各所に連絡して、ベンダーに投げれば終了です。
どうなんでしょうね、こういうの。
クラウドの流れによりサーバの仕事が減っているらしくて非常に衝撃を受けました。
それでは、今後将来に向けてサーバの運用や構築の仕事は少しづつ減り20年後くらいいにはほとんどなくなってしまうということでしょうか。
サーバの運用や構築の経験があればすぐにクラウドの仕事が出来るというわけではないということでよろしいでしょうか。クラウドはただサーバがでっかくなたようなものだと予想していましたがちがうのですかね。じゃあLINUXOSの知識もいらないのですかね。
また、お話がずれて申し訳ないのですがwebエンジニアやネットワークの運用などの仕事は今後も減ることは無いということでしょうか。
もう若い人にはサーバでは食っていけない時代になるんですかね。
今までとった資格(LPICやMCTS)やLINUXのコマンドなどは無意味になるのですかね。
もしそうならあまりにひどいとおもいませんか??金返せと...
webエンジニアやネットワークにいまから切り替えようかなと思ってます。
やっぱり仮眠とりますよね。
仮眠とらないとさすがにきついですもんね。
夏休みになると人員配置も考えなければいけないですよね。
また、夏になれば障害率があがりますからねー。
データセンタ内でシステムが完結すれば
季節とか関係ありませんが、
そうでないシステムは夏は大変ですからねー。
1次対応の役割は迅速に障害があることを伝える
というのが基本ですからそれを守ることが第一ですよね。
体制次第ですが緊急性の切り分けまでできればベストですね。
でも、まあ普通はそこまでやらないですよね。
だいたい上流下流の案件型であれば
監視の仕事は運用と障害対応がメインですから
そんな感じになると思いますよ。
私はクラウドの流れは流行り言葉じゃないように思います。
サーバは減っていくは真理だと思いますよ。
システムは仮想化の流れをたどっていますし。
ただ、自社サービスや顧客情報をどこまで
外部にクラウドに託すかってのは
ちょっとまだ見えてこないですね。
クラウドのサーバ構築・運用はできる人の世界ですからねー。
AmazonやGoogleが今のところ目だっている状態ですし。
何もサーバ屋さんじゃなくてもインフラを展開できる
ってのがクラウドの流れですからねー。
でも、受注型の案件は縮小しても基本なくならないでしょうし。
まっ、20年先の未来なんてわかりませんよ。
3年先ですら不透明ですし
クラウドだってすぐはじまりすぐ終わるのか、とかですよね。
ITを産業革命時代にあてはめれば
まだまだこれからですからね。
10年前と今のITを比べてみてください。
次の10年もころっとかわっていると思いますよ。
そこに身を寄せるのがIT関係で仕事をするってことだと思います。
やはり、高度な経験もったサーバエンジニア以外は今後厳しくなる可能性が高そうですね。
ネットワークの方はクラウドのおかげでより仕事が増えるのですかね。
やはり、先を考えるとwebエンジニアやネットワークにいまから切り替えるのもありかなと思いました。
でもDOSやシェルスクリプトやperl、linuxのコマンドなどはネットワークに行っても無駄にはならないと思います。
自分もNTT系列で運用監視をしています。
A帯(9:30-18:30)とB帯(17:00-翌10:00)の2交替制シフトです。
A→A→B→休→休→A→・・・のローテーションです。
ちなみにB帯の時は一人です。
生活リズムが狂うので辛いです。
構築担当は運用にタッチしないので、冗長化とかあまり考慮されておらず、頻繁に障害が発生します。
予算や事情はあるでしょうが、障害を出す事でお客様からの信用を失っていくわけだから、運用の事を考えた設計が本当に大切だと痛感します。
2交替制ですか。
話を聞くぶんにはけっこう多いのでしょうか。
構築担当が運用にタッチしない。
これがすべてを物語っているように思いますね。
ただ、言い方を帰ると
構築は運用にタッチしたいがするメリットが薄い
という構造上の問題があるように思います。
つまり、ほぼ放置することも可能なんですよね。
たとえばサーバではなく、ルータ・スイッチを扱っていた場合、
上位層のアプリケーションがからまない分故障率が低いです。
となると、当然、そんなに人はいらないし、
いざ、故障となっても現物を入れ替えるだけですからね。
本当に大事なのは運用で
技術力も一番求められるところだと思いますよ、本当は。
だから、私は構築から運用まで面倒をできる距離が
近い方法がいい方法のように思います。
構築から運用まで面倒を見ても、その運用場所が遠いというパターンが多いでしょうが。
目指すべきところはそこだと思います。