障害対応手順のないコワさ

ものすごく重要なシステムなのに、シングル構成でかつ、障害対応手順が存在しない。

テキトーに構築してそのまま逃げてった。

いろいろな運用ツール（シェル）を置き土産においてってくれてるんだけど、ビミョーな構成変更にまったく対応できていない。

自分で読んで試して修正すりゃいーじゃん、といわれてもアンタ、ここは本番環境だよ？
「それがＳＥだろ！」とか、精神論でゴマカされる。


ＳＥへのパスがない。「運用だからって甘えんなよ！　自分らで解決しろよ！」といわれる。

ロクな引継ぎもされていない。
設計書もマニュアルも、ホントウに知りたいことはまったく書いてない。


。。枚挙にいとまがない。
こんな恐怖体験をしてオイラは「育った」。

とにかく、壊れたときの対応が全く確立されていないシステムを任されるってのは、恐怖だよ。
よくやれたと思う。

「教えてほしい」というと「自分でやれ」と逆ギレされるし、構築したヤツはもういない、と。。
壊れたところを見たこともないシステムの障害対応手順を作れ、という。「想定でいいから！」と。。

オレ一人のハナシじゃなくてさ、落ちたら何千人ものユーザ影響が出るシステムの、運用の体制がそんなんだっていう事実は、それはもう犯罪じゃねーの？

しかもそのシステムの運用を、外注の小僧に任せっきりにする。


こんなんばっかだから、オイラもう運用エンジニアはゼッタイイヤだと思っている。オペレータならいいんだよ、（たぶん）障害のときのコール先が明確だからさ。
オペレータから受けて２次対応するポジション、バックに頼れるＳＥがいなくて自分で何とかしなければならないポジション、っていうのがさ、もう今となっては恐怖。
ゼッタイやれない。

そんなことばっかやらされてるから運用エンジニアのモチベーションは落ちるし、優秀なヤツは誰もやりたがらない。結果、３次請けぐらいの外注に丸投げしちゃう。

運用はカンタンだっていわれたことあるけどさ、そりゃ、マニュアル類と障害対応フロー、手順がきちっとしてるシステムだったら、カンタンだよ。

世の中の「システム」と呼ばれているものの９０％以上はそうじゃねーから。
そうじゃねーシステムの運用が、ヒトを常に募集してんだよ。
だから、できるかぎり近寄っちゃいけない。

オペレーションマニュアル

オイラの数少ないアピールポイントというかね。。「オペレーションマニュアルを書ける」という。

ＳＥにはオペレーションマニュアルを書けないんだよ。それはプライドの問題でさ。
オペレーションマニュアルは、明文化されない判断を要する分岐を入れてはならないんだ。つまり、手取り足取り、事細かに、マニュアルに盛り込んでいかないといけない。
それがＳＥにはできない。「それぐらい自分で考えろオラァ」とぶんなげちゃう。「テメーらもエンジニアのはしくれだったら自分で考えろ！　なんでオレがこんなに手取り足取り書いて示してやらないといけないんだあああ！！」とブチ切れる。

「書けない」ってのは語弊があるのかもしれんけどな。いつかは書くんだから。
最後の最後の引継ぎ工程で、何をモチベーションに書くかって差別意識だよ。

こういうヤツがほとんどだから、ＳＥとオペレータの溝なんて永久に埋まらない。
でもさ、ＳＥが「オマエらもエンジニアのはしくれだろ？」と考えること自体間違っているんだよね。それこそが差別なんだよ。

オイラはIT土方と「ITセコム」をいったりきたりしてるから、書ける。

[IT土方]ITPro

初めて責任者が語る！全日空システム障害の対策と教訓
-ITベンダーに対して、要望はあるか。
悪い情報ほど早くほしい。障害を起こした原因であるスイッチはシスコシステムズ製で、2001年10月にNECが納入したものであった。世界に類似事例が4件しかなかったが、障害が発生した今から振り返ると、他社の事例は非常に貴重な情報になったかもしれない。我々だけだと、情報収集能力は限られてしまう。ITベンダーは、保守運用を通して他社での事例も知っているはずで、情報交換なりアドバイスはしていただきたい。
開発する時には一生懸命やってくれる。開発が終わって定期保守の段階になると、関係が薄くなってしまう。技術陣も営業担当も終わったプロジェクトとして位置付けられてしまう。我々にとってみれば、システムが稼働し続ける限り運用しなければならず、航空機の運航管理など重要度の高いシステムもある。やはりほかの企業で何が起こっているのか新鮮な情報がほしい。
システム刷新を検討する時には、ITベンダーは元気よく来てくれるが、定期保守段階に入った時期にITベンダーとの関係をどうすれば良いのか考えていきたい。NECとも対応策を協議している最中だ。
（おわり）
なんか「ザマミロ」的な。。
ベンダが、運用が始まると逃げちまうなんてのはアタリマエのことで、それをいまさらどうこういってもしょーがねーだろ。テメーらが運用にカネかけねーのが問題なんだよ。 それは、「世界」全体でいえることなんだ。世界中のどの会社も、運用（ランニングコスト）にカネをかけない。だから、問題が起こる。
わかれよ！　はやく！　カネをかけないで良質な運用を実現するなんてできねんだよ！　高いカネで、構築で頑張ったＳＥ囲っちまえよ。スカウトして自社にひきずりこみゃいーじゃんか。そのぐらいやってみろ！
アンタの会社は運用ＳＥに１０００万／年出せるか？
全日空は、一発のシステム障害で数億円の機会損失、そして、運用改善の実行にさらに数億円かかったそうだぞ。そのリスクをリスクとして抱えたままにしておくか？デキる運用ＳＥ抱えたほうが「ほんのちょっとだけ」そのリスクは回避できると思うぞ。そのかわりほんのちょっとだけだ。その「ほんのちょっと」をいくらに換算するか、だ。

[IT土方]運用案件じゃカネがどこからも出てこない

以前書いたけど、自分が今、いちばんキラいな現場のシチュエーションがあって、それは、客先の情シスの一画に常駐して、運用管理を委託されていて、かつ、運用べったりではなく、現場で発生する小案件（サーバの増設だの撤去だのバージョンアップだの）が常にちょこまかと発生して、それにいつも追われまくる、みたいな現場。

こういう運用の現場だと、ゼンゼンだめ。カネがさ、出てこないのよ。客から。

案件も運用費の一部だからさ。。　運用コストは前年度予算で決まっているから、運用からスピンして中規模案件が発生したとしても、予算内でしかやれん、と言う。でもやってね、と。

まあその予算云々のハナシは、営業間で調整すりゃいいハナシなんだけど、問題は工数なんだよ。

運用からスピンする案件だって、スキルは必要なんだ。だから、それなりのＳＥ調達しなきゃならねんだよ。
はっきりいってしまえば、案件を運用エンジニアに任せるわけにはいかないんだよ。カレらを弁護すれば、彼らは運用管理に注力すべきであって、案件のために運用業務に穴を空けるわけにはいかない。

でも実態は、運用エンジニアには案件はこなせないんだ。
ＳＥ連れてこないと。
でも、ＳＥは運用の現場にきたがらない。。
それはね、モチベーションの問題ももちろんあろうが、単に安いからじゃねーの？　と思うようになってきた。
客がカネだせねんだから、ＳＥに出せるカネもタカがしれてるわな、そりゃ。


結局、運用の現場だから運用のエンジニアを連れてくることになるわけだが。。元来受け身の姿勢の運用エンジニアを案件に特化して投入させたところで、ゼンゼンつかえねー。
やる気があったとしても、だ。まず、仕事に対する「姿勢」から劇的に変えてもらわんといかんのだ。
カットオーバまでにシステムをつくりあげる仕事と、それをメンテする仕事というのは、まったく違うんだ。この間は、カンタンに往来できるもんじゃないんだよ。

つくりあげる仕事ができる人間がメンテができるかというと、ほぼできない。
カレらは、継続してこつこつと仕事をする、ということ自体バカにしてるからな。


世の中がさ、いくら口では「運用というのは大事な仕事」とかなんとか美辞麗句並べたところで、客がランニングコストにカネを出す風潮になっていかなきゃ、ゼッタイに状況は改善されない。

常に、運用というのは見下されたままだ。
早くだれか、「オレは運用を見下している」とぶっちゃけてくんないかなあ。そこから議論が始まるんだけどな。

オイラは常に「見下されている」視線を感じてきたから、このギョーカイで。だから、仕事は大キラいだ。でもなんで続けてるかって、カネが必要だからだよ、生きるために。

[IT土方]システム運用のキーワード

こないだ、運用ツールのブローシャのハナシを書いたんだけど。。

そういえばさ、オープン系のシステム運用の設計書って、そのうたっている内容が、笑っちゃうぐらい、そのときのギョーカイのトレンドを反映している。

なんだっけ、データセンターへの移行だとか、コスト削減とか、統合化とか、ソフトウェアの自動配付だかなんだか。。まあどの時代にも誰かが流したキーワードをそのまま設計思想にも反映させているわけだが。。
（そう考えると、まだまだこのギョーカイは未熟だ）

そして今は、どこもかしこも気持ち悪いぐらいに「ＩＴＩＬ」。
でもこれはゼッタイに、単なるトレンドに過ぎない。断言してもよい。あまりにアタリマエのことだ。

どうせ何年か経ったらまた別の「わかりやすい」キーワードに皆のっかっていくんだから。

「サーズ」だの「エイズ」だのと同じだよ。

[ＩＴ土方]運用管理ツールのブローシャ

７、８年ぶりに運用管理ツールのブローシャをじっくり見たんだよ。（メーカは特に名を秘す）
見事なまでに進歩してねーな、という印象。

どうやら、管理なり監視できる「こと」は、以前と比べて増えているらしいが。。
こういうツールのキモは、「設計」だぞ。いや、「設計しやすさ」とでもいおうか。

そのツールで何ができるか、なんて、ほっとんど意味はねーんだよ。
あれも管理できる、これもできる、なんて、バラ色の運用管理、みたいなことをばんばん書きやがって。。
それが、変わってねー、っていうこと。

こういうツールって運用の現場の生の声をフィードバックしてんのか？
こういうツールってどれだけ設計構築に工数かかるか、わかってんのか？　いや、開発する側はわかってんだろうなあ。。　わかってて、黙ってる。

これほどイニシャルコストがかかるツールも珍しい。そして、そのコストがこれほどまでに軽視され、削られ、サイアクの品質のままにカットオーバされ、大迷惑になるツールも珍しいだろ。アタリマエだ、設計に工数かけねーんだから。

それとさあ、もうひとつのキモは、ツールそのものの維持管理だよな。パラメータチューニングとかさ、ノードが増えてときの対応とか、日々変わってゆく管理・監視要件の変更への対応とか。

そういう変更に、まったく柔軟に対応できん。

維持管理に必要なのは、ドキュメント！　運用管理ツールのドキュメントというのはロクなもんが残らん。

このあたりは、ベンダは知らん振りできるからな。「自分たちはこれだけのことができるツールを開発しましたが、あとは知りません」と。


とにかくさ、運用管理ツールとは「システム」そのものなんだ。インフラに組み込まれる管理「システム」。
と、いうことは、要件定義～設計～構築～運用という一連のライフサイクルをあたりまえのように通過させなきゃいけないんだよ。
でも、やらない。。　上層部は、エンジニアリングなしで、いれればなんとかなると思ってやがるからな。。　話戻すと、ブローシャーの書き方が悪いんだよ！


それとなあ、もっと腹立つのが。。「ＩＴＩＬに準拠」ってなんだよ！
たまたまトレンドだからってそのキーワード盛り込めばちょっとは売上げが上がると思ってからに。

ＩＴＩＬに準拠するのはツールじゃねんだよ！　ツール依存じゃなくて、運用の現場そのものを改革するの！　そして、上層部がやるんだよ、それを！
逃げんじゃねーよ。まずその泥臭いところからやるんだよ。ツールを入れるのはその後の話だ。
たかが運用管理ツールが運用の現場を劇的に変えるわきゃねーだろ！！


SAP R/3が企業の業務システムを劇的に変えたか？ トレンドだからって軽い気持ちでツール導入して、既存の業務フロー、「抵抗勢力」の反対にあって業務がぐちゃぐちゃになった会社を知ってるぞ？

ただ漫然と、エンジニアリングを考えずに導入して、未だ苦しんでいる企業はたくさんあるんだよ。（自業自得で、ザマミロだけどな。。）


そんなに売りたいんだったらベンダ自身がコンサルで入って設計構築して運用引継ぎまでやれよ。破格値で。
売った途端に逃げ腰にならねーで、それぐらい腹くくって売れよ。

[IT土方]運用への引継ぎ

引継ぎで、常に、どんなシステムでも難色を示すヒトたち。。

自分が引き継ぐ側だと、ヤツらはなんだかんだと文句を言って引継ぎをシブりやがるので、「融通きかねーな！」と思ってしまう。

でも、自分が運用の側になると一転、設計構築側に対してどこまでも抵抗勢力になってやろうか、と意欲満々になる。特に、引き継ぐ側のヤツらが高飛車だったときはね。

このへんのサジ加減がホント、難しいところで。。
現在のギョーカイ慣習では、ドキュメントや手順書の類をキチっとそろえて運用部隊に引き継ぐなんて、まずムリ。
そういうスケジュール自体組めないんだよ。

だいたい、システムがカットオーバーされて、初期運用でバグとかが出て、それが収束したあたりで、さあ、引継ぎ考えよう！となるんだけど。。

そこからわたわたとドキュメント整備するわけだが、もうその頃は抜けたくてうずうずしてるわけね。「やっと解放される！」と。。
そんな心持で、精度の高いドキュメントなど作れるはずもなく。。

さらに、カットオーバ直前から、初期運用にかけて、課題が残る。「運用にカバーさせる」ってやつだ。
これがけっこう、ムチャなお願いになることが多い。
でももう、システムは走ってるし、いまさら改修加えられないから（工数ないし）、運用でカバーできるならやって！　と、お願い半分、逆ギレ半分になってゆく。

結果、運用側の構築側に対する不信感は、さらに高まる。


この、引継ぎで発生するいざこざをどうするか、って、ギョーカイ全体でマジメに考えたことはあるんだろうか。
その根っこには、運用に対する差別意識がある。構築が運用に対して差別意識を持とうが、他業界からみたらすべて同じ穴のムジナなのに。。

これだけ、短納期で安く、を求められてしまうと、もうダメだろうね。質が悪くとも安く、早く上げることに注力してしまうから、そして、その質の悪さはすべて運用がかぶることになる。

インフラの未来は暗い。。
もっともっとシステム障害やら、全国ニュースになる大規模なインフラの停止とか、起ってほしいものだ。そうしないとこの悪循環は変わらないから。

[IT土方]サルでもわかる手順書づくり

みんなウンザリしてるよ。あんまり、おおっぴらにしないけど。

もちろん、オイラもウンザリしてるよ。「サルでもわかる」手順書づくりは。


つくってもつくっても、直しても直しても、きれいに引き継げない。
だって、引き継ぐ相手は「我々はサルですから」っていってるようなもんだから。
「判断が入る手順書なんてコワくてつかえません！　ウキー！」ってな。


みんなウンザリしてるから、ますます、手順書づくりと運用引継ぎから逃げる。

アバウトなまま、運用リーダ呼んで、ちょっと説明して「あとヨロシク、ゴメン！」しちゃう。政治力も駆使してさ。

プロジェクト収束のどさくさにまぎれて、引継ぎもままならないまま、逃げちゃう。「もう工数ないから。。」って。

「運用設計」の中で全部手順書書いて、運用に引き継ぐようにする、なんて、マトモにやらねーもんな。

学生の頃、歴史やってて、戦後史なんてもう教科書の終わりのほうだから、前がオしちゃって、駆け足でしかやらないでしょ？　それどころか、「各自みておくように」で終わっちまうこともあった。それと同じ。


運用側は、こういう仕打ちを受け続けて、ますます卑屈になり、設計構築部隊に対するウラミを募らせてゆく。

カットオーバ後に構築担当者に連絡すると、逆ギレされる。「もう契約終わってんだよ！」と。ポンコツなシステムを納品した事実はすべて棚に上げ。。

ムカシ、運用側にいたとき、構築屋からことごとくこういうことやられてさ。。
逃げられまくった。


でも時代は変わり、運用側でも「最低限の文化的生活」を送るために、権利を主張することができるようになってきた。運用側、というか客側というか。

「ドキュメントの品質が良くなければ運用に乗せることはできません」と。いえるようになった。

なんでもかんでも申し送り事項にして「運用にカバーさせればいい」なんて運用がいないところで勝手に決める、っていう時代は終わった。

[ＩＴ土方]運用要員への無用な期待

現在の、いろんな組織のシステム運用体制ってさ、問題なくシステムがリリースされるという前提でしょ。
滅多に壊れない（はず）から、運用要員はチューニングのスキルはいらない。本来は。

何が言いたいかというと。。
現実問題、システムというのは欠陥だらけでリリースされる。バグが潜んでいる、っていう話ではない。
運用体制にはそぐわないオペレーションがありまくり、ってことだ。構築上発生した問題点はすべて「運用への申し送り事項」となり、リリース時期だけは遵守され、あとはよしなに運用でカバーしてくれ、となる。

でも、運用にはそれをカバーするだけのスキルを保持していない。
「保持していないのなら、持てよ」と上層部は言うかもしれない。
でも、なぜ保持していないかって、ランニングコスト切りつめすぎなんだよ。
カネをかけないから高い人材が集まってこないの！

安い人材は、自律的に育とうともしないんだよ！
それをわかれよ。


システムが運用上の欠陥だらけでリリースされるのは、オープン系の宿命。
バグは、徹夜でFIXするのかもしれないけど、「運用設計」のバグは、なおさない。

ムカシの運用要員は、おぜんだてができているシステムをオペレーションすればよかったんだ。でも今は、カットオーバ時点では欠陥商品だから「おぜんだて」はできていない。だから、追加構築を自律的に行えるぐらいのスキルが運用部隊には必要なはず。でも、そこにいるのはいわゆる旧態依然とした「運用要員」。

運用要員が「おぜんだてがないから何もできません」というリクエストを上げたとして、それに「おぜんだてがないと何もできないのかよ！」と逆ギレするほうが間違っている。

責任は、欠陥だらけのシステムをリリースしたほうにある。

特に責任を問われるべきは、リリース判定でＯＫを出した客だよ。このギョーカイは客に責任を問う仕組みがねーからな。。

運用の現場で自律的に成長しろ、と暗に期待するのも間違っている。成長を期待するのであればそれなりの教育カリキュラムを提示するべきだ。もちろん、外注に対して、だ。

あのウザい「セキュリティ研修」ばっかじゃなくってさ。。


とにかく、ランニングコスト削減のトレンドに反して、もっとカネ出してさ、もっと構築センスをもった運用要員を集めるこった。「少数精鋭」でな。

イニシャルコストをかけて開発構築の精度を上げる気なんて、さらさらないんだから。それだったらランニングコストにカネかけんのが当然。
「プロアクティブ」に対応しなさいよ。欠陥だらけのシステムリリースしといて、結局ツケはまわってくんだから。ヒドいことになる前に手を打ちなさいよ、といっている。

そんな、ビジネスの常識すら通用しないギョーカイだ。

[IT土方]手順書！

とあるＰＪというか現場で、何度も何度も、「○○プロセス再起動手順」みたいのをコピペして渡して、運用部隊に引き継いだことがある。

つまりどういうことかというと、そこの運用部隊は引き渡される手順書をナレッジとして蓄積することなく、ただ形式的に受け取るだけ。
その「○○再起動手順」は、複数のサーバで、全く同じ手順でオペレーションできる。だから、「引継ぎしなくともいいでしょ」といっても、「いえ、ルールですので手順書はつくってください」といわれる。
だから、タイトルとかヘッダフッタだけ変えて、渡す。（たとえば、「Ａサーバ○○手順書」を「Ｂサーバ○○手順書」に変えて、日付を変えるぐらい）

確かに、ホスト名とかパスワードとかは変わってくるのだが、そういう可変パラメータは別台帳で管理すりゃいいだけの話だ。サーバ追加日もそっちの台帳に書いておけばいい。

だから、その運用部隊は、「○○プロセス再起動手順」を、サーバごとに20本ぐらい持ってる。
ヤツらは、それを、システムごとに、１キングファイルにファイリングしたいわけ。だから、システムごとに受け取りたいのね。

その手順が、たとえばセキュリティホール発見！　とかそういう理由で、変わってしまったら、どうするんだろうか？
ヤツらはゼッタイ、それぞれの更新はしないと思うね。

で、オペミスが生まれるんだ。（ちょっとザマミロ）


今考えると、ホント、クダラないね。

運用部隊にナレッジを蓄積しよう、という気があるのだったら、たとえば、Ａシステムでも○○プロセス再起動手順があるが、今回運用に引き継がれるＢシステムの同一プロセス再起動において、何か相違はあるか？　と、逆にＰＪ側に聞くことができる。

それで、相違が発生する（前手順、後手順があるとか）んだったらＰＪ側に新たにつくってもらえばいいし、なければ、パラメータだけ受け取ってあとは運用側で処理すればいい。そうすればＰＪ側も助かる。


これは「氷山の一角」であって、構築部隊は運用部隊に対して、この例と似たような偏見を持っている。

まあオイラは歳もとったし、広く浅く構築も運用もやってるから、どちらの言い分もわかるっちゃわかるんだが。。

インフラは、運用とか構築とか関係なく、どこもかしこも「変わらなければならない」んだよ。