デプロイの度に障害が起きるシステムを安全にした話 - エムスリーテックブログ
鉄道では個人の注意力だけでなくシステムにより安全を確保している。 写真は「タブレット閉塞式」のタブレットを交換する様子。１つの区間にはタブレットを持った列車しか進入できないため、衝突事故を防ぐことができる。（作者 Spbear [CC BY-SA 3.0 ], ウィキメディア・コモンズより） こんにちは、エムスリーでソフトウェアエンジニアとして働いている小本です。 私は基盤開発チームという、エムスリーの複数のサービスにまたがって使われるシステムを開発・運用するチームに所属しています。 基盤開発チームが担当するシステムの１つに、会員向けメルマガの配信システム「メールコンシェルジュ」があります1。 エムスリーはメールコンシェルジュで１日数十万通のメルマガを配信しており、機械学習でメルマガを最適化する施策2などもメールコンシェルジュの存在が前提になっています。 このようにエムスリーにとって重要な
いますぐ実践! Linuxシステム管理
「いますぐ実践! Linux システム管理」はこちらです。 メルマガの解除、バックナンバーなども、以下からどうぞ。 https://www.usupi.org/sysad/ (まぐまぐ ID:149633) その他、作者に関するページは、概ね以下にございます。 https://www.usupi.org/kuri/ (まぐまぐ ID:126454) http://usupi.seesaa.net/ (栗日記ブログ) https://twitter.com/kuriking/ (twitter) https://facebook.com/kuriking3 (facebook) https://jp.pinterest.com/kuriking/pinterest) https://www.instagram.com/kuri_king_/ (instagram) [バックナンバーのトップへ
[悪徳商法？支店]: エンジニアのモチベーションを根こそぎ奪う！たった７つの魔法の言葉
１．テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 ２．とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rustに移行する理由の大部分は、C++11以降の更新とガイドライン順守で消えますか？まあ、CargoこそC++にほしかったもののひとつでしょうけど。
