2012年のバグをふり返る
2012年もお終い。1年の終わりには、その年に作ったバグをふり返ってみることにしている。各マイルストーン毎にふり返りを行なっているとは言え、1年のまとめとして改めて総括してみると自分なりに反省点が多い。クローズしたチケットを遡りつつ、昨年の反省点が生かされているか、今後の障害の未然防止に如何に繋げていくか、勉強になる点ばかりだ。
外の世界に目を向けてみると、今年もバグやシステム障害のニュースが少なくなかった1年だったと思う。自分たちの作っているシステムは何の関係も無いところばかりだけど、そんな事例を集めて議論してみると、また新たな視点を自分の中へ持ち込むことが出来そうな気がする。失敗事例は宝の宝庫であり、他山の石とすべきなのだ。
まずは、2012年といううるう年に絡むものから。4年に一度しか巡ってこない事象だし、何かのシステムでトラブルが起こるだろうと待ち構えていたら、予想通りに問題が発生していた。2月29日という状態になることは分かっているはずなのに、開発者もテスト担当者も納期に追われて忘れてしまうのだろう。
問題のバグは、「番組の録画予約を行った場合、予約ができないことを意味する『×』マークが表示される」というもの。残りHDD容量に余裕がある場合でも、容量不足で録画できないという旨が表示されるという。
シャープのBD/DVDレコーダーでうるう年に関連するバグ | スラド
2012年はさらにややこしてく、うるう秒という特異な状況も発生していた。うるう年に比べるとマイナーだし決まった期間で起こるとは限らないけど、これも過去に何度も起こっていた事象なので、これが歴史上初めてという訳でもない。それでも、カーネルというOSの中枢で障害が起こっていたとは、意外な感じもする。
MySQLが被害を受けているので調べていたのですが、原因はLinuxカーネルの不具合とのことです。
2012-07-02
カーネルと言えば、ext4を壊すバグも発見されていた。ノートマシンでは使っていないので気が付いていなかったけど、障害は意外な所に潜んでいるのだ。
Theodore Ts'oによれば、この問題は、カーネルを短期間で二度正常にリブートすることで起こるのだそうだ。
本の虫: Linuxのstableカーネルにext4をぶっ壊すバグが発見される
大規模なシステム障害も相次いだ。多大な工数をかけて作り上げたシステムでも、毎日安定して稼働させるには人間の状況判断が欠かせないのに、そこにミスが有ると簡単に障害を引き起こしてしまう。システムを生かすも殺すも人間次第なのだ。個人的には、人間の判断が介在するとロクな結果に繋がらないと経験的に分かっているのだけど、全ての対応を全自動で処理できるようになるまでには、まだ時間が必要なのだろう。
診断ツールには問題がなく、きちんと状況を分析していたが、診断レポートを読み解く人間の側に問題があったとの見解を示した。
東証、システム障害の原因は「人為ミス」、診断レポートを“解読”できず | 日経 xTECH（クロステック）
この更新プログラムを検証環境で実行するという手順を踏んだにもかかわらず、バグに気づかないまま本番環境で実行された。この結果、意図しないファイル削除が実行されてしまいデータが消失した。
データ消失障害のファーストサーバが中間報告、「データは復旧不可能」 | 日経 xTECH（クロステック）
昨今では珍しくもないが、携帯電話端末の障害も相変わらずだ。開発に携わった人曰く「スキルも経験も無い開発者が作っているのだから当たり前のこと」だそうだが、特異な状況でのみ発生するという報告を見ると、過去のノウハウも事例も共有されない（ありがちな）開発現場の様子が思い浮かぶ。
不具合は、特定のエリア環境において、SO-01Eの電源が強制的に落ちて、再起動するというもの。東京23区で発生しやすいとしており、現時点では23区内でのみ確認されている事象としている。
「Xperia AX SO-01E」が23区内で強制再起動の不具合 - ケータイ Watch
また、最近では意図的にバグを含んだソフトやシステムをリリースして、話題に上がって知名度が広まった時点で修正するという姑息な事例も増えてきたようだ。もちろん、ホントにそのような悪意が有ったのか否か不明だけど、状況証拠を見る限りそのような判断をされても仕方ないように思う。この種の炎上マーケティングは来年以降も形を変えて続いていくのだろう。
commがバグで保護すべき個人情報が漏洩しやすい仕組み（実装だけでなく、個人情報に関わるテストの不十分さも含めて）になっていたと推定できます。つまり、（特に改善内容や対策に関する発表が無い以上、）素直に考えれば今後も同じようにバグがあった場合に、本名が表示されてしまう可能性がそれなりに存在すると予想されます。
「過去のバグ」を参考にcommやLINEを使って大丈夫なのか考える | LINEの仕組み
初期には端末のセットアップで多くのトラブルを抱え、電子書籍ストアでは、公約したように販売書籍の量が増えていかない。書籍の検索にも問題が多い。楽天Koboに期待していた人を落胆させる結果となった。
【西田宗千佳のRandomTracking】問題の原因、解決のめどは? 「楽天Koboに何が起こったか」 - AV Watch
ピンポイントでバグや障害の原因を取り上げると、実は単純なものが多い。障害レポートを読んで「そんな単純な原因だったのか」と脱力感にとらわれることも珍しくもない。そんな容易な問題を見つけられなかったのかと部外者から叱責されることもある。しかしながら、今のソフトウェアやシステムは、無限のピンポイントから成り立っているのだ。個別の箇所を取り上げるのは容易だけど、全体像という視点を持たずに議論することは無意味だろう。
障害をゼロに無くすことは不可能だけど、最悪の結末を避ける程度の判断力は、開発者側に備わっていて然るべきだ。バグが有るから問題なのではなく、バグの発生に対して適切な対処を取れないことの方が、実は問題なのかもしれない。開発現場ではバグとの闘いが続く。それでも前進しなければならないのだ。
それでは、皆さま良いお年を。
