全維持管理担当SEへの挑戦状!「なれるSE2 基礎から学ぶ? 運用構築」
というわけで、日本全国のSEと書いてSlave Engineerと読んだりするSystem Engineerが待ち望んだ、なれるSEの2巻が出ましたよ!
- 作者: 夏海公司,Ixy
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/10/10
- メディア: 文庫
- 購入: 35人 クリック: 244回
- この商品を含むブログ (89件) を見る
ネットワーク構築をメインにした前回に比べると、今回はシステムの構築から維持というあたりをメインにしていて、もう何というか、読んでいていたたまれなかった……
とりあえず、今回の内容にツッコミを入れてみると……
- 新人が自分の歓迎会の幹事をすることはある。うちで実際にあった
- 運用部門とは仲良くするべき
- メモリのエラーなら、syslogにメッセージでるんじゃね?
- 今回の件で一番怒られそうなのは、現場の保守員
ざっと考えてみるとこれくらいかなぁ。
とりあえず、あの障害対応はあり得ない。
shutdown -h nowするにしても、現場の判断のみで行うのはありえない。少なくとも、顧客には了解取るし、運用部門にも周知させる。
いや、対応としてああいう状況になれば、クラスタ停止なんてコマンド効かないだろうし、shutdownするしかないだろうなぁ、とは思うんだけど、それにしてもいきなりやるのはあり得ないというか、そんな状況だったらtelnet(もしくはssh)でloginとかできないんじゃね? と思うんだけど、そうすると、コンソールからTOC入れるしかないんじゃね? と思うんだけどなぁ。
この場合としては、クラスタの副系にloginして、H/BLANからコンソールloginしてTOCかな。
ただ、メモリ不良で数十秒間隔でダウンアップとか、その時間だとOSも上がりきらないと思うんだけどなぁ……どのレベルでダウンアップしてるのかは不明だけど、普通クラスタ構成だったらDB落ちて上がらない時点でF/Oさせると思うんだけどなぁ。
考えられるとすると、メモリ不良からDBのプロセスもサーバプロセスも全てハングアップして、監視のタイミングだけ復旧する、というのを繰り返してる状態とか?
あまりにも都合の良すぎる障害だろうけど、そういう状態しか考えられないかなぁ。
あと、レスポンス悪かったら、まずはDB疑うだろ!
話の都合とはいえ、なぜそこに辿り着かない!
そんなので「優秀な技術者」なんて、名乗れると思うな!
というわけで、System Enginnerというのは、少ない情報からこれだけのことを考えてしまう因果な商売なわけですよ……
今回は、室見さんのツナデレが少なくてちょっと残念だなぁ、と思ってたら新キャラ来たよ! Fだよ!F!ぺったんこなツナデレよりも、新キャラだよ!
うん、SEは、やっぱり運用さんと仲良くしないと仕事にならないしね!
というわけで、ぼくも姪乃浜さんと仲良く運用したいです。