2020年2月アーカイブ

合併に伴うシステム統合がうまくいかず、二度の大規模障害を起こし、20万人月と揶揄された新システムへの一本化開発(本によれば最終的に35万人月らしい?)、というSI的システム開発の苦悩の象徴的なみずほ銀行の内情を描いた本。日経コンピュータが、みずほの中の人に怒られること承知で、内部の分析や推測や提言にまで踏み込んで意見している点が特徴となっている。

銀行にとって中央にある勘定系システムは心臓部であり装置産業であるから経営者層で適切にマネジメントしなければいけない、という点を強調している。お金の流れをシステムで一元管理しているからこそ、必要な業務を正しく定義し、それに寄り添うためのシステムを定義し開発し運用していかなければいけない、というある意味根っこのところを主張している。間違っても、合併に伴う各行の主導権争いやらリスクの先延ばしに注力して目を背けるようなことをしてはいけない、と記している。

過去のシステムトラブルのときにも本が出ていて(二度目の本一度目の本)、それを読んでいる人からするとあまり目新しい話は出てないと思う。期待に反して(?)、ようやくシステム一新できたのでこれから新サービスに注力していくよ、という宣伝なのか応援なのかな内容が付け加えられた点が新しいか。

もはや神話とも都市伝説ともなっているみずほ銀行の話だけど、ふつうの人にとって見れば「どことどことどこが合併したんだったっけ?」「三連休たびにATM止めやがって」程度なのかなと思う。IT革命とか言われたのもはや20年前、その当時とは比べ物にならないくらいIT技術ありきの社会となっている現在では、ふつうの人でもこの手のシステムの裏側の話は一般教養として知っておいたほうがいいのかもしれないと感じる。

ITだコンピュータだソフトウェア開発だといっても、こういうたくさんの人が関わる開発だとならではの苦悩がたくさん出てくる。そういう開発に苦悩したりする実例を知ることができるという意味では貴重な本。ただ過去の本を読んでいるならあえてこれを買う必要もないのかなと思う。

以下気になった点の列挙。

P61 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「三行で用語を統一するところから」 大きな会社やプロジェクトほどありがちで、用語や意味が違うからすれ違いが起こる。言葉が企業文化でもあるため、開発初期ほど言葉遣いには十分に注意したいと思った。

P64 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「開発のベンダが異なる」 先の用語と同じで、所変われば考え方や文化が変わるので、ここでも十分な意思疎通をとっておく必要性をよく感じる。

P73 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「ツールでしかプログラムを生成しない方針」 うーん、個人的にはこれはどうなのかな。一歩譲ってその方針を受け入れるとしても、ツールの仕様に口出ししたり場合によっては変更したりすることができないと個人的には辛いと感じそう。

P77 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「開発拠点の確保にも苦労した」 これは最近良く感じる事が多い。いくら音声通話やテレビ会議システムが充実してても、意思疎通の限界を感じることが多く、同じ場所に集まれるに越したことはない。

P83 第4章「緊張と重圧、一年がかりのシステム移行」より「重要な移行作業に三連休を充てた」 リアルタイムにATM休止のお知らせがアナウンスされるのを見ていたけど、障害だけは何が何でも避けようとコストをかける覚悟を持って作業しているのがよくわかった。

P153 第7章「検証、昆明の十日間」より「四億円の未回収が生じている」 銀行はこの手の締めに非常に厳しいというイメージを持ってるんだけど、それが出ること承知で、10万円まで引き出せる特別対応を行ったというあたり、トラブルのときの影響範囲がハンパないんだなと思わされる。

P168 第8章「重なった三十の不手際」より「システム装置産業とも言える金融機関」 結局ここなんよね、お金を扱う業界だったけど、今やコンピュータ上で数値を計算して決済するだけの業界になりつつあって、融資も銀行以外から行うことが増えた結果、銀行なのに紙幣や貨幣を扱いたくないというのが実情だったりと。「AIに置き換わる」とか象徴的に報じられるけど、そうじゃなく、銀行の役割が終わりつつあるのが実情よね。

P170 第8章「重なった三十の不手際」より「ハードウェアではないからだ」 未だにハードウェアとしてのコンピュータを提供してるベンダが全責任を追っているような開発をイメージしてしまう人っているのかな、と疑問に思いつつも、まぁ*年前はそれが当たり前だったわけだし、古い人向けにはこういう説明が必要なのかとも思った。

P183 第9章「一年をかけた再発防止策」より「情報伝達体制を見直し」 夜間バッチ処理って、タイムリミット...というかタイムラインが必要な作業なので、この手の決まりごとを決めておくのは必要不可欠だよねと思った。

P207 第10章「現場任せが諸悪の根源」より「四行統合」 形としては合併したのに中の組織が全然合併していない、てのはよくある話で、P212「割り勘にできないという理由で、三千九百万円に値切った」とかいう信じがたい話も信憑性が増してしまう。

P237 第12章「大混乱の二〇〇二年四月」より、いい顔してるねこの写真、このあと地獄のようなシステム障害が発生するわけだけど。

...縦書きの本って個人的には受け付けない体になりつつある...

Linux memo 2020/02/04

● SIGKILLのハンドル
SIGKILLはユーザランドでシグナルハンドリングできずそのままプロセスが終了させられる。が、しょせんはシグナルの扱いなので、kernel内では他のシグナルと同様の扱いをされる。つまり、寝ていたタスクは起こされ、kernel空間の外へ追い出す方向に処理が進み、システムコールの呼び元の直前までいって、そこでタスク終了処理が行われる。

ただ、SIGKILLは、スレッドが終了するだけでなくプロセスが終了するので、SIGKILLをハンドルしたタスク以外の同じプロセスに属する他のタスクも終了する。それがどこで行われているかというと、kernel/kernel/signal.cのcomplete_signal()の後半、sig_fatal()のときにwhile_each_thread()で&t->pending.signalにSIGKILLを立てている。つまり、最初にシグナルを受けたスレッドと比較して起こされるまでちょっとだけ遅延する。

● ext4のinodeのブロックマッピング
filefrag(8)コマンドを使えば、inodeの中身の論理位置とblockデバイスの位置とのマッピングを表示できる。
filegragはioctl(FS_IOC_FIEMAP)で情報を取得している。
ext4のextentでできるだけ物理連続にfilemapを作ろうと思った場合、ioctl(FALLOC_FL_KEEP_SIZE)もしくはposix_fallocate(3)でpreallocするという方法がある。
参考:C言語で、作成したファイルが断片化しないようにする方法。(Linux編) - Qiita
https://qiita.com/Sickly_Life/items/d1c73ca2b497910576fc

● ext4のquotaの設定
ext4でquotaを使うかどうかは、superblockのFilesystem featuresにquotaが立っているかどうかで決まる。
quotaの情報は、Filesystemの中の隠しinodeに記載されている。inode番号は、EXT4_USR_QUOTA_INO(==3), EXT4_GRP_QUOTA_INO(==4)のもの...じゃなくて、superblockのs_usr_quota_inum, s_grp_quota_inum, s_prj_quota_inumに記載された番号になる。通常は、mkfs.ext4やtune2fsがFilesystemを作るときに、EXT4_USR_QUOTA_INO, EXT4_GRP_QUOTA_INOを指定しているはず。(Todo: s_prj_quota_inumの初期値)
quotaを使うためにはCONFIG_QUOTAを有効にする必要がある。ext4はkernel/fs/quota/以下にある共通コードを使ってQUOTA機能を実現する。inodeの中身を直接渡して、中身には踏み込まずに、QUOTQ機能を実装しているようにみえる(ToDo: inodeの中身)
参考:ext4のDisk Quotaあれこれ - Qiita
https://qiita.com/takeoverjp/items/0f4966bbead0b5e3bf4f
ちなみに、quotaに限らず、inodeの中身をダンプしたい場合はdebugfs(8)コマンドのdumpが使える。

このアーカイブについて

このページには、2020年2月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2020年1月です。

次のアーカイブは2020年4月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

Powered by Movable Type 7.5.0