お昼休みを経て午後問題へ。(´・ω・`)
お昼休みの際にエクレアを食べた。午後問題は3時間30分という鬼畜の長丁場である。それに耐えられるよう、将棋のプロ棋士がおやつに甘い物を食べるのにあやかって、糖分蓄積用のスイーツを食べることが僕のルーティーンなのである。
しかし、この長丁場は非人道的だといつも思う。こんな長時間の連続集中を要求されることって他にある? 午後Ⅱと午後Ⅲの間に休憩が無いのは、恐らくは試験会場の手配と試験官の勤務時間を定時までに終わらせなければいけないからだと想像するが。
しかし、こんなに過酷でも何だかんだでみんなやれてるから不思議なものである。(´・ω・`)
午後Ⅱー1
参ってしまったのが、午後Ⅱー1。4つの問題からの選択制だが、全部分からんの。(;´・ω・`)
昔はこの中から1つくらいは過去問と重複していたから、過去問を勉強することで逃れられたのだが。去年、今年と過去問からの出題が無いからぶっつけ本番。
これは一体、日頃からどういう情報に接していれば、こんな単語と出会うんや? 過去問のトレース以外に勉強手段を持っていないから、これをやられると致命的に困る。
ただ、2の「デプロイ、運用、サポート活動において、ソフトウェア開発プロジェクトの管理者が対応すべきことと懸念事項を述べよ」は、何を聞かれてるのか分からんが何とでも書けるからオラオラと書いておわり。
何か書けば少しは点も貰えるだろう、ということで次へ。
午後Ⅱー2
Ⅱの2は、1を選択した。
障害発生時の再発防止策として、テストプロセスの改善について述べるもの。昔ながらの伝統的な気配がする問題だ。無難である。
この問題のポイントは「想定するシステムと障害の内容を最初に定義せよ」という指定があること。これは閃いたね。
これね、クソみたいな原因で発生した障害を例に出してはアカン問題だ。
例えば、「テストケースのうっかり漏れで障害が起きた」とか、「プロジェクトが余りにも短納期で碌に試験もやってなかったから障害が起きた」とか。
そういうアホみたいな例を出すな。高度な事例を持って来なければいけない。
その時に僕の脳裏に浮かんだのは、あれは僕が社会人2年目だったと思う。当時、僕はEDIのシステムに関わっていたんだけど、発注システムから発注したのに、EDIに発注ファイルが来ないという発注漏れ障害があった。
原因は、Webとバッチの競合だ。Webとバッチで同じレコードを更新するんだけど、トランザクション管理が甘くてステータスが逆戻りし、バッチ処理の対象にならず永久にそのまま、という構図で発生する障害だった。
これはWebとバッチの処理が絶妙に被らなければ発生しないタイミング勝負のバグだから、テスト工程で普通にポチポチしていても再現しない。負荷テストツールを流用して、Web画面とバッチをガシガシ競合させまくる試験をやっていれば、検知出来た可能性もあったんだろうなぁ。
あの時は、負荷テストは性能をチェックする為のテストでしかなく、トランザクションの正当性をテストする為には使っていなかったのよ。
つまり、「障害の原因は、バグに再現性が無いから。改善策は、負荷テストツールの有効活用」。
どうよ。高度な内容でしょ?
「障害の原因は、担当者のスキル不足。改善策は、有識者によるレビュー」みたいなタワケた論文を書いたヤツはアウト。m9(・`д・´)
20年に渡りあちこちで障害を起こしまくってきた僕だからこそ書ける文章。これで勝負や。(´・ω・`)
