老年の主張:どうしてシボウフラグを自ら立ててしまうのか

時系列で「お知らせ」を並べるとゾーっとします。

1.何かを修正した

「Fujitsu MICJET コンビニ交付」サービスで発生した印刷障害について : 富士通Japan株式会社

今回の事象の原因となった、一時的に交付申請が集中した際の強制的な印刷処理に関するプログラムを修正いたしました。これにより現時点で本事象が解消され、適切な証明書発行処理が行われていることを確認しております

→「交付申請が集中した際の強制的な印刷処理」っていうのは、排他制御を理解していない偽エンジニャがときどき発明するmutex解除フラグ」みたいなやつですかね。このシステムの場合、複数のシステムなのでmutexではなくて非同期通信で排他制御をしているとは思うのですが

2.また直した(シボウフラグ1)

「Fujitsu MICJET コンビニ交付」における新たな印刷障害について : 富士通Japan株式会社

上記の3つの条件を満たす自治体様は当該自治体様1団体のみであり、他の自治体様では発生しえないことを確認しております

→「他では発生しない」は言っちゃダメなやつw

→この「3つの条件」が3つじゃなくて2つに見えるのはわたしだけ?

3.言い訳(シボウフラグ1’)

川崎市様における証明書誤交付ついて : 富士通Japan株式会社 (fujitsu.com)

本事象の原因は、2か所のコンビニで、2名の住民の方が同一タイミング(時間間隔1秒以内)で証明書の交付申請を行った際に、後続の処理が先行する処理を上書きしてしまうことによるものです。本事象の原因となった当該プログラムの不具合は、既に修正および入れ替えを完了しております。なお、当該プログラムは川崎市様以外では使用されておりません

→「他では発生しない」は言っちゃダメなやつ^2w

4.←イマココ

当社「コンビニ交付」システムに対するデジタル庁様からのご要請について : 富士通Japan株式会社 (fujitsu.com)

→「とにかくシステムを止めて点検しろ」というのは、各種「検証団体」によってシボウフラグを回収されてしまうのを避けるための手段

タロウチャン(または取り巻き)は、分かってますね。

これまでの経緯を見て、「検証団体」による「壮大な意地悪テスト」を繰り返されると、未摘出の潜在バグや問題点が大量に摘出されるのは必須です。

それを避けるには止めて、「世間が興味を失う」のを少し待った方が良いです。

ただ、今回の場合、慌てて3回目の修正をして、デグレっちゃうんじゃないかなと心配になります。

「過負荷でエラー」が出るのを「排他を強制解除して誤動作」しかも修正2回目とか、デグレあるあるすぎてなむなむちーんですね。

教訓:

バグを取っても、「もう大丈夫」「今回だけの特別な事象」は言っちゃダメ。

開発者目線で「別のバグ」でも、利用者からしたら「同じバグの再発」なので・・・