エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
英語圏の開発者に初めてバグレポートを出す時の5つのポイント【連載：コピペで使えるIT英語tips】 - エンジニアtype | 転職type
IT用語はアメリカ発の言葉がほとんど。でもいざ英語で書こうとすると「何と書いたらいいのか分からない……」という時もあるはず。そこで“コピペでOK”なIT英語表現を紹介！ 開発中に発見したバグを同僚に報告したり、デベロッパーサイトからバグレポートを提出したりした経験は多くの開発者があるだろう。が、開発が日本人だけのチームならレポートも日本語で構わないが、英語圏のメンバーがいる場合やOSSプロジェクトなどであれば、英語で報告しなければならないシチュエーションも出てくる。 今回は、シンガポールで働くエンジニアのDさんに、英語でバグレポートを書く際に気をつけるべきポイントや心構えなどについて教えてもらった。 Dさんに聞く、バグレポートの基本 バグ報告は、開発者にバグの存在を認識してもらい対処を促すことが目的だ。 もし目の前でバグを再現してみせることができるなら、これに優る伝え方はない。しかし開発者
プログラマ格言(2006)
2006年くらいに書いたプログラマ格言が発掘されたのでおいとく。おおむねダジャレです。 * PHPを笑うものはPHPに泣く * 意味: 「PHPなんてまともなプログラミング言語じゃないよ」と笑っていたら仕事でPHPを触るはめになってしかも既存のソースが汚かったりして泣く。 * 教訓: 好き嫌いを通せるようにえらくなれ。 * ソースが知れる * 意味: 変な挙動をするソフトをさわっていると、動き方から間違ってるパターンと作った人のレベルがなんとなく透けて見える。 * 教訓: どうやったらうまく動くか探すのも仕事のうちらしい。 * ひいきのwiki倒し * 意味: 「wikiはすばらしいツールですよ！」 と、とにかくwikiを導入してメンテ不良のページを大量につくってしまう。 * 教訓: 情報共有ツールは使う人のメンテナンス能力が一番のネック。 * ライブラリからボタ餅 * 意味: 延々ぐぐっ
進撃のプログラマー : 小野和俊のブログ
■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人
［論点2］適切なテストを行えば発見できたか
みずほ証券はバグの原因を東証の重過失とする根拠をいくつか挙げているが、中でも準備書面で多くのページを割いたのが、「簡単なテストを行えばバグは必ず発見できていた」という主張だ。 みずほ証券は、東証から提出を受けたソースコードを解析。バグの原因となった修正プログラムについて、修正部分を直接的に確かめるテストか、修正が他のプログラムに影響を及ぼさないことを確認する「回帰テスト」のいずれかを実施していれば、今回のバグは容易に発見できたはず、という意見書を提出した。今回東証は、修正プログラムのテストについての資料は「既に存在しない」として開示していない。 みずほ証券によれば、テストで想定すべきケースは「たかだか二つ」だったという。「テストケースは無限に想定され得るから、今回のバグを見つけるのは困難」という一般論は、今回のケースでは当てはまらない、という主張である。 二つのケースとは、ある特定の条件下
［論点3］どんな開発手法を適用すべきか
みずほ証券がテストの件に加えてもう一つ、東証の重過失に当たるとしたのが「システムの開発手法が適切ではなかった」点だ。開発ベンダーに適切な開発手法を求めなかったため、発注者である東証も責任を免れないとする。 開発手法が適切ではないことを説明するために、みずほ証券は具体的な事例を示した。東証がソースコードを修正する際に、「モジュール詳細定義」などのドキュメントを修正していなかった点だ。 東証はこの事実を認めた上で、「一旦コーディングが済めば、その後の修正は、全てソースコードを中心に行うことが最も効率的であるから、モジュール詳細定義を改訂していなかったことに問題はない」と反論した。「コーディングが済めば、ソースコード自体が、最も詳細なドキュメントである」というわけだ。 これに対してみずほ証券は、ソフトウエア工学の専門家による意見書を引用し、こうした東証の主張を真っ向から否定した。「システムを保守
誤発注裁判が改めて問う「バグは重過失か」
「東京証券取引所に重大な落ち度があることは、火を見るより明らかです」。2013年3月18日、東京高等裁判所での第一回口頭弁論。みずほ証券の代理人である岩倉正和弁護士は、東証の株式売買システムに潜んでいた誤発注を取り消せないバグの概要を説明する大型パネルを法廷内に持ち込み、25分にわたって熱弁を振るった。 対する東証代理人の山田和彦弁護士は終始落ち着いた口調で「合理的信頼性を有するシステムを提供できていれば、たとえバグが一つあったとしても、債務不履行には当たりません」と述べ、13分ほどで弁論を終えた。同日、裁判は結審した。 みずほ証券と東証による株誤発注裁判の控訴審は、両社がソフトウエア工学上の論争を戦わせる異例の展開になった（図1）。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
