あるDB障害の話
前回のブログでこんなことを書いた・・・
：
ある全く無駄な運用JOBがあった。それは、ORACLEのAUDIT文なんだけど、元々AUDIT ONになっているのを再度ONするだけ。
でも、オンライン中に実行するのでAUDIT対象のユーザがログイン中、もしくは同時にログインするタイミングがある。
するとORACLEのdc_usersでデッドロックが発生することがあるらしい（特にRAC環境）。
AUDITの設定を変更する際、dc_usersへ排他ロックが掛かる。でもロック処理でバグがあるらしい。
サポートがバグと認めた途端、彼らはバグであることを盾に元々の無駄なAUDITのJOBを改変することを拒否した。
自分達の無駄な運用をメンツにかけて認め無くなかったのだ。
：
これにはさらに追加がある。
サポートで個別パッチを作ってもらい、適用手順とその効果も確認してもらった。さて、あとは顧客の許可を得て当てるだけだと思ってた。
#実際、顧客はいつ解決するんだと責められていた。
しかし、ここからがさらに長かった。
パッチを当てる前に自分達で検証するとSIerは言い出した。
で、バグの状況を踏まえて、こんな検証してこういうデータを取れば良いんでは？と提案したのだが、全く無視された。
全然関係の無い業務JOBと性能をパッチ当てる前／当てた後で比較して影響ないことを確認するんだと言い出した。
そのためにさらに1ヶ月以上の時間をかけて検証計画を立て、工数掛けて問題ありませんというデータ取りした。
これでやっと実施かと思いきや、今度はシステムバックアップを取らないといけないと言い出した。パッチが戻せることを確認しているにも拘わらず。
バックアップを取るにはOSを一度止める必要があるし、そうなるとWeb/APの再起動やら本番業務JOBのリスケやら大変な作業になる。ヤな予感がした。
案の定、JOBの設定ミスやら、OS再起動するときにストレージのマウントに失敗して起動できないやら、別の障害を何度も発生させた。
これには呆れるばかりだった。こいつらは、これが本当に仕事だと思っているようだった。無駄な運用、無駄な検証試験、無駄なバックアップ、顧客にその分工数請求できるからなんだろう、きっと。
IT業界はブラックだとか生産性云々なんてやつらには毛頭ない。
こんな連中が日本のIT業界大手のだから、日本のIT業界は永遠に変われないと思う。
ある現場の話
今通っている現場の話。
Windows/Hyper-Vメインのシステムというのも初めてなんだけど。
使っているパッケージはベンダーもしくは社内の別事業部任せ。
マニュアル、もしくはネットで調べた実装手順を碌に調査・検証しないまま本番実装。
ちょこちょとと試すくらいなら良いかも知れないけど、本番運用するなら性能や長期運用時のCPU/メモリ/ディスク使用、バグ等々いろいろ検証してから本番運用すべきだと思うんだが。
障害が発生するとログ・エラーメッセージをサポートへ送付するだけ。自分達でログを調べたり、運用で退避できないか調査しようとしない。
サポートから返ってきた対処療法をするだけ。サポートも背景を知らないからそれくらいしかしてくれない。
本当は、そもそもその実装が正しいかどうかを振り返ったりもしない。障害が続くと対処療法に対症療法が重なり、復旧手順が複雑になる。
こんなこともあった：
ある全く無駄な運用JOBがあった。それは、ORACLEのAUDIT文なんだけど、元々AUDIT ONになっているのを再度ONするだけ。
でも、オンライン中に実行するのでAUDIT対象のユーザがログイン中、もしくは同時にログインするタイミングがある。
するとORACLEのdc_usersでデッドロックが発生することがあるらしい（特にRAC環境）。
AUDITの設定を変更する際、dc_usersへ排他ロックが掛かる。でもロック処理でバグがあるらしい。
サポートがバグと認めた途端、彼らはバグであることを盾に元々の無駄なAUDITのJOBを改変することを拒否した。
自分達の無駄な運用をメンツにかけて認め無くなかったのだ。
着任して数ヵ月しか経ってなかったが、こいつ等と一緒に仕事したくないと真剣に思った瞬間だった。
ITの分業と専門化
先日、ITは分業化と専門化ができてないと書いた。
IT系って、製造業を経験しないで、アイディアだけで先行するから工業製品を作るという経験をしてないせいなんだろうなと想像する。
例えば、工業製品としてちゃんとした機械を製造販売するのであれば、
- 設計・製品開発
- 生産技術
- 製造
- 検査
等々、分業化してそれぞれのメンバーが専門化している。
設計、製造、検査といった工程を全部同じ人が担当するなんてあり得ない。
ソフトウエアは一つの部隊で顧客の要件を聞いて、業務分析して、仕様書書いて、プログラム書いて、テストしてる。
その方が小回りが効くし、低コストで作れると思う。
だが、その弊害が気になる。つまり、同じ人がずっと工程を続けるので、途中途中の設計書始めとしてドキュメント系がいい加減になるということ。
きちんと作らなくてもその後の工程も自分が担当するからプログラム完成を優先しておざなりになりがちである。
その結果、チームメンバー内で設計書不備で不整合が発生したり、後で引き継いだメンバーが仕様を十分理解できなくなってしまう。
専門化という観点でも顧客の要件を聞いて設計仕様におこすスキルとJava等プログラムを書くスキルは全く別物だと思うのだが、なぜ同じ人がやるのか不思議で堪らない。
キャリアを積む上でいろんな工程の経験を積むべきだと思うが、一つの案件で複数の工程を兼任すべきだはないと思う。
もう１つ思うのはDBAってスキーマとRDBMS構築を兼任するのか/できるのかってこと。
自分もDBAの経験は長いが、業務を分析してスキーマを設計する（テーブルを設計する）のとインフラに近いRDBMS構築は全く別のスキルだと思う。
そりゃ、データベースエンジニアとしてER図の書き方くらいはできなくてはいけないと思う。でも、要するにドライバーやスパナの使い方を知っていても機械設計図が描けるかは別問題。
未だにPL/PMも十分な理解ができてなくて、「データベース」というキーワードだけで兼任することがある。特に小さな案件でメンバーが少ない場合そうである。
でも、DBAの間でも認識が異なる人が居て、兼任しても良いと考えている人も居た。
でも考えて欲しい。スキーマの設計ってアプリの根幹であるはずだ。それをデータベースというキーワードだけで、業務を理解できていない人に任せるのは危険だ。
それもRDBMS構築と兼任なんてできるはずもない。ユーザー業務も分析しつつ、インフラチームと相談しながらRDBMSの設計・構築ができるスキル・時間がある人はスーパーSEだ。
この件もキャリアを積むために、ある案件ではRDBMS構築、次の案件では、業務分析をしてスキーマ設計をやっても良いと思う。が、1つの案件で兼任はNGだと思う。
IT業界の資格と転職事情
ぶっちゃけ、IT業界で転職できる人材・必要とされる人材は、40歳未満なら深夜残業・休日出勤を全然厭わない人、40歳以上なら10人以上のチームのプロジェクトリーダー・プロジェクトマネージャーを何度か経験した人というのが実際に転職活動してみた実感。
データベーススペシャリスト持ってるとかORACLE MASTER Gold持ってるとかいっても結局参考程度で、仮に採用されてもそういう資格を考慮して配属されるかは確かではない。
情報処理業界は情報処理試験とかベンダー資格とかPMPやらITILやらいろいろ資格があるけど、結局、認定試験であり、この程度の知識・スキルがあります（若しくは、かつてありました）という証明だけ。
他の業界だったら、たとえ一週間勉強した程度で合格する試験でも合格してないと法的に携われないという業務もあるのにIT系の資格はなんか重みを感じない。
IT系の資格って決して易しくはないと思うけど、結局その程度なんだという実感。
IT系エンジニアは勉強大好きで自宅に環境作って検証したり、夜・休日と自主的に勉強会参加してスキルアップに余念がない人が多いけど、それがキャリアアップとかあまり結びつかないとあまりにも悲しいではないか。
ITのスキルアップはピース数も全体像も分からないままパズルを組み上げるようなもの
IT系の皆さんは特に自主勉強するほど熱心が多いと思う。
IT系の勉強って実装テクニックとかトラブル事例とか経験値を上げるための勉強が多い。
自分もずっと興味ある勉強会へ参加してきたんだけど、あるときふと思った。
ITのスキルアップってピース数も全体像も分からないままジグソーパズルを組み上げるようなものだと。
しかも皆で１つではなく、一人ひとり個別のジグソーパズルを組み上げているからなかなか完成しない。もたもたしていると古いピースは陳腐化して消えてしまう。
これを延々と続けるのだ。
そう思ったら、急に無力さを感じてしまった。
個人がスキルアップを続けるのは良い。無駄どころか、企業は自主的な勉強会へ参加したら交通費を出す等もっと支援すべきだと思う。
いつも企業は人が居ない人が居ないと言ってばかりいないで、それから技術者の個人的なスキルアップばかり期待しないで、誰でもITを構築できるよう考えるべきだと思う。
個人が持っている暗黙知を集成して組織の形式知にして工夫を企業として努力するべき時期が来ていると思う。
そしてその形式知は設計書の形にすべきだと思う。社内のナレッジデータベースを作ったりすると、誰も参照しないでいるとすぐに陳腐化して廃れてしまう。
つまり、設計書とか標準化して中に書いてある目次に従ってある程度までは品質を上げられるようにそろそろ考えるべきが来ていると思う。
その第一歩として社内の設計書等過去の案件を集計したいと思ってたけど、上司が「そんなの意味あんの？」そんなことしているなら外で稼いで来いとばかりに現場へ出されてしまった。
このままだとIT業界はただただひたすら個人のスキルに頼った技術の継承に終わってしまうと危ぐするのだが。
今のIT業界に思う事
初めてブログ書きます。esabataDといいます。
元々はRDBMSのシステムエンジニアでした。
これからIT業界で思いついたことを書き綴っていきたいと思います。
どうかよろしくお願いします。
この業界で思ったのが日経コンピュータの「木村岳史の極言暴言！」
（この方の記事を支持しているわけではないけど、ときどき「そうだよね」と賛同することはある）
で指摘されたように、お客様の業務に関して業務改善とか生産性向上とかいう割に自分たちの仕事について何も改善していないということ。
深夜残業・休日出勤、それが何？という顔をして仕事している。
そして、仕事の分業・専門化が進んでいないこと。
製造業であれば、設計・生産技術・製造・検査等々、別の部門・人が工程に従って引き継いでいくのに、この業界はずっと同じメンバー。
この方が確かに少人数で小回りが利くメリットがあるとは思うけど、ソフトウエア開発を一種の製造業とみなすと未発達・未成熟な組織体制ではないだろうか。
ITという産業は確かに若いのでこれからできていくのかも知れないが、この業界へ20年以上関わってきたけど、そういう方向へ進むのか訝しい気がします。
