Kubernetesが導入される企業が徐々に増える中で、「これまでインフラレイヤに触ったことがないのにKubernetesを触る必要が出てきた」という開発者の方もいるのではないかと思います。そういった方にむけて「Kubernetesとはなにか」からはじまり、Kubernetesに乗せたアプリケーションが動かなくなって困ったときのトラブルシューティング方法を紹介するスライドです。 残念ながら資料内で動画を再生することができないためターミナル画面の画像のみになっているスライドがあります。
Kubernetesは怖くない！開発者のためのインフラトラブルシューティング入門
Kubernetesが導入される企業が徐々に増える中で、「これまでインフラレイヤに触ったことがないのにKubernetesを触る必要が出てきた」という開発者の方もいるのではないかと思います。そういった方にむけて「Kubernetesとはなにか」からはじまり、Kubernetesに乗せたアプリケーションが動かなくなって困ったときのトラブルシューティング方法を紹介するスライドです。 残念ながら資料内で動画を再生することができないためターミナル画面の画像のみになっているスライドがあります。
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
COCOA騒動メモ
COCOA が動いていなかったことで大臣が謝罪してひと騒動起きている件について、開発者視点からのメモを残してみます。 なぜこのメモを書いたのか 世間的には不正確な情報で叩ければOKの風潮が強くてしんどいので、正しいと思われる情報を拾い集めたものです。中抜きwww 王子wwwww Xamarin wwwwwwww みたいな人にはあんまり興味ないかと思います。 調べ始めたきっかけはこのツイートと引用されたblog記事ですが、記事の内容が違うことはすぐに指摘されて撤回されていたのですが、実際どうだったのかさらに調べてみました。 接触通知アプリ COCOA とはなんなのか 仕組みとか何かは公式サイトでもみてもらうとして。この件で煽っている人でも一部理解できていない人がいるようなのですが、直接的な効果としては 保健所が濃厚接触者追跡をする際の手助けとなるためのアプリ ということになります。アプリをイ
Webアプリケーションの障害対応について改めて意識すべき点ややれると良いことをまとめる - stefafafan の fa は3つです
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
データ移行をしただけなのに…（起こってしまったメール誤配信） - Qiita
この記事は本番環境でやらかしちゃった人のアドベントカレンダー9日目の記事です。 https://qiita.com/advent-calendar/2019/yarakashi-production もう15年以上前の事なので記憶も定かではないところがありますが、ご容赦下さい。 当時の状況 当時自分は30人くらいの、孫請・曾孫請を中心に受託開発を行う小さなSIerに居ました。 この会社、自社製品も一応あるのですが売上のメインは圧倒的に受託開発で、 PHPやPerlでのガラケーサイトの開発やら、Javaや.NETを使った業務アプリケーションの開発、大手プロバイダシステムの開発保守など、わずか3年ほどの在籍期間でしたが、実に多彩な開発案件があったように思います。 プロジェクト内容 あるWebサイトのシステム移行でした。 Windows Server上に構築されたIIS+ASP+SQL Serv
いつものように本番作業してたはずなのに - Qiita
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景（前提条件） いっていに昔の話です ETL（データ加工）サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境
ドジっ子巫女エンジニアがサーバーを止めた件と職業倫理 - いま作ってます。
まとめ。 技術者は技術的事項については社会的な責任を持つと自認すべきだよ。 でも独自の倫理に則り独断専行するような役割を期待されてはいないので自重すべきだよ。 放置するのは社会への裏切りだけど、独断専行するのも社会への裏切りだよ。 本件に関する個人的感想としては、以前からフォローしてたのにTLから消えてしまって悲しい。 参考 シャットダウン事件と発見者の責任 | 水無月ばけらのえび日記 http://bakera.jp/ebi/topic/4415 Togetter - 「巫女テスター(17歳)、欠陥システムをサーバーごとシャットダウンするに至った顛末とその後のお話」 http://togetter.com/li/135263 Togetter - 「巫女さんの引退宣言」 http://togetter.com/li/136949 専門家と倫理 ばけらさん曰く、 あえて語弊のある言い方をす
システム障害との向き合い方 @sinamon129 #tokyogirlsrb
これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。 いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。 TokyoGirls.rb Meetup vol.1 https://techplay.jp/event/716251
大規模memcached障害と私 - Qiita
この記事は ex-mixi Advent Calendar 2017 19 日目のエントリーです。 こんにちは。@bonnu と申します。 株式会社ミクシィには2006年１月から2012年３月末までの間、６年と３ヶ月ほど在籍していました。その後株式会社FreakOut（現在はホールディングスとなっています）に転職。そこからさらに転職を重ね、現在は株式会社GameWithでサーバーサイドを主としたエンジニアをやっています。 ミクシィに入社した当時はまだ社名が株式会社イー・マーキュリーで、入った翌月に社名変更したタイミングでした。なので希少な「イー・マーキュリー」の名刺を持っていました。私より後に入社した他のエンジニアのみんなからよく珍しがられたのを覚えています。 今回はOB・OGによるアドベントカレンダーということで、在籍していた頃に体験した障害について少しお話したいと思います。 （※ 当時
「障害に捨てるところなし」というお話をしました - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。 キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。 では、どうぞ！ 障害にすてるところなし サイボウズ株式会社の横田です。 「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。 運用障害の話 まずはじめに、今回のお話をするにあたりまして 運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。 これからも、弊社製品をよろしくお願いいたします。 クラウドの規模と稼働率 障害の話をする前に、サイボウズの
システム障害で消耗してるあなたに：失敗から学ぶための取り組み「Failure teaches Success」 - クックパッド開発者ブログ
こんにちは！広告エンジニアのレオです。最近、システム障害を起こしていますか？クックパッドも例外ではないです。毎月、何かしらのシステムに何かしらの障害が起きてしまいます。その際、早く気づき、速やかに対応することによって被害を最小限に留めるように努めます。そして、システムやデータを正常な状態に復旧させます。 正常な状態に戻した段階では対応はまだ完了していません。問題の本当の原因は何なのか、またその再発をどうやって防止するかを考えて手を打つまでは、障害の対応が完了したといえません。予防しない限り、また同じ過ちを繰り返すことになってしまいます。 失敗は成功のもと 根本原因分析、そして再発防止は大事な作業ですが、とても難しい作業です。クックパッドでは、これらを少しでもやりやすくするために、ルールと仕組みをまとめています。この仕組みを「Failure teaches Success」（略してFtS）と
敏腕派遣SEの火消し日記
現地担当者との調整が悩み 仕事の内容が現地に出張しての設置作業から，実装担当者を遠隔コントロールする仕事に変わってきました。そんなわけで，仕事の流れとしてはテスト環境の構築を自分のところでやり，手順を確認したら現地のSEにメールなどで指示して作業をしてもらうような感じになりました... 2006.10.20 この仕事の醍醐味 最近，うるさいサーバーのそばで仕事をしているせいでしょうか。耳が遠くなりました。まだ30代なのですが，たまに実家に帰ってテレビを視ていると，親からテレビの音量を注意されます。最近の仕事はというと... 2006.10.13 クールビズの効果で涼しげな音が... この記事が掲載されるころには，少し季節外れになっているかもしれませんが，ご勘弁ください。前回の記事に引き続き，またまた検証環境をセットアップすることになりました... 2006.09.29
[Failure teaches success] データの持ち方を失敗した - Rejasupoem
社内には障害が起こったりすると、次回失敗しないように "Failure teaches success" っていう知見を蓄積するシステムがあるのだけど、この度 プライベートで書いてるアプリ で障害を起こしてしまったので、知見をブログに書くことにしました。 概要 今日の夕方にmiyagawaさんからAftershowが表示されないと連絡をいただきました。 発生原因 アプリ内でのデータの持ち方にいろいろ問題がありました。 Rebuild.fm for AndroidではEpisodeは端末のsqliteに保存していて、ActiveAndroidで読み書きしていましたが、リスト表示するために何かのカラムでソートする必要があったのだけど、日付は "Jun 15 2014" みたいに入ってくるからソートしづらいなと思って、urlを見てたら "http://rebuild.fm/10" みたいにスラッ
mixi大規模障害について 解明編 - mixi engineer blog
こんにちは、システム本部技術部たんぽぽGの森本です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev
宇宙ロケット失敗の悲劇：動画6選 | WIRED VISION
前の記事 攻撃型のウイングスーツ『Gryphon』(動画) 宇宙ロケット失敗の悲劇：動画6選 2009年12月 4日 Annaliza Savage 米国やロシアの宇宙開発は、全体的には進展しているものの、ときおり悲惨な事故が発生し、人々に大きな印象を与える。こういった事故のいくつかを動画で紹介する。 到達高度は1.2メートル 1957年12月6日、人工衛星を軌道に打ち上げるという米国の初めての試みは、同時に初めての失敗となった。 ケープカナベラルの発射台を離れた2秒後、『Vanguard TV3』ロケットは推進力を失ってそのまま発射台の上に落ち、燃料タンクが破裂して爆発した。到達した高度はおよそ1.2メートルだった。 [Vanguard(ヴァンガード)は米国海軍が開発したロケット。1957年10月4日にソビエト連邦のスプートニク1号が打ち上げられたのに対抗するため急遽打ち上げられたが、失
NatsuLion for iPhone クローン (略) から学んだこととかまとめ - @takuma104 log
NatsuLion for iPhone クローンがライセンス違反で売られてる件 - @takuma104 log はてなブックマーク - NatsuLion for iPhone クローンがライセンス違反で売られてる件 - @takuma104 log たくさんのブクマ & コメントありがとうございます。こんなに反響があるとは思いませんでした。。やっぱりライセンス問題は気になりますよね。ということで、今回の件でいろいろ勉強したこととか、コメントいただいてたのの回答とかまとめてみました。 (追記) ちなみに上記のエントリに追記しましたが、Twittervilleの中の人からメールをもらっていて、事態は収束の方向です。現時点で先方はTwittervilleアプリの販売を取り下げているようです。 New BSD License (と MIT License) について コメント欄でご指摘いただ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita
「サル軍団」にシステム障害を起こさせる、Netflixの驚異的なトラブル撲滅法
