ゼロから始めるシステム障害対応フロー - Qiita
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
Webアプリケーションの障害対応について改めて意識すべき点ややれると良いことをまとめる - stefafafan の fa は3つです
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
システム運用の現場でしか学べないことは他メンバーに積極的に経験してもらうべきだった - seri::diary
基本的に自分はタスクを拾いすぎてしまう傾向にある。それに加えて比較的朝型なこともあり、前職ではエンジニアの中で一番朝早く出社していることも多かった。*1 その結果どうなるかというと、朝出社して見つけた運用上のトラブルは大体自分がとりあえず手を付ける状態になっていた。前日の夜間バッチやその日の早朝に動くバッチがコケて問い合わせが来ているのでそのリカバリをする、前日にデプロイした後レスポンスが高くなってアラートが出ているのでその調査をする、web appがやたらと500系エラーを吐いているのでBugsnagを見る、等々。 出社している以上無視するわけにもいかないというのもあるが、見つけてしまうと放っておけない性格ということもあり最優先でこれらの対応をしてしまっていた。お陰で前職で触っていたproductについてはかなり広範囲の知見があり、その行動がそれなりに社内での評価につながっていたのではな
SRE チームを設立します - Cybozu Inside Out | サイボウズエンジニアのブログ
運用本部長を務めている山本泰宇です。 運用本部は社内の情報システムを担当する情報システム部と cybozu.com など自社クラウドサービスを運用するサービス運用部からなる部門です。 本日、サービス運用部にて SRE チームを設立しました。この記事ではチーム設立にいたった経緯と今後の活動計画を紹介いたします。 Site Reliability Engineering (SRE) とは 今年の 3 月に O'Reilly から出版された "Site Reliability Engineering" で有名になりましたが、Google のプロダクトやサイトを安定運用するための活動やその活動に従事する人・チームを指します。特徴としては基本的にソフトウェアエンジニアからなる集まりで、自律的な仕組みや自動化を日常的に行っていることです。 サイボウズでも 5 月から社内で SRE 本の輪講を開催し、理
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス／アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく、人や事象によって違うとは思いますが。 なお、障害検知手法とか、サーバのコマンドとか、コードのデバッグ手法とか、具体的なことは一切出てきません。手続きと思考プロセス的な話です。 障害対応フローチャート 一般的な感じだと思いますが、障害報告から対応完了までのフ
Gotanda.pm #6 で障害について話してきた #gotandapm - weblog of key_amb
こんにちは、@key_amb です。ご無沙汰しています。 最近ブログの更新が遅れてまして、なんとなく申し訳ない気持ちになっている今日このごろです。 なんと、2ヶ月も更新してなかったんですね。*1 さて、前回の Gotanda.pm #5 では、テーマ(「高速化」でした)ガン無視の LT をしましたが、今回はちゃんと「障害」というテーマに沿って発表をしました。 障害を防ぎ、サービスを守るために #gotandapm from IKEDA Kiyoshi 時間がかなり余ったようで、もう少しネタを用意しておけばよかったなと思いました。 今回はこれまで仕事上、いろいろと障害やアラートの対応をやってきた中で、自分なりに大事だと思っている考え方をまとめてみました。 で、その中でどういうツールを使っているかなどの紹介をしました。 どちらかといえば概論的な話で、各論にはあまり踏み込んでいないのですが、何か
システム障害対応に対する考え方について
ヴィス @2vis 社内システムが普通に12月32日なって 「どーなってるんですか！」とユーザに言われて、 しらねーよ俺作ってねーよとは言えず呼び出されたことがｗ 2014-01-01 02:57:47 ヴィス @2vis 後、汎用機で1月1日になったら急に送受信が止まって呼び出されたときに… MMCFに「expire：20〷」って設定がされてた。 訳：期間満了って事 こんな地雷設定しこむんじゃねー！と叫びたくなったよｗ 2014-01-01 03:00:57
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
「AWSを活用して少人数で複数のサービスを運用するコツ」〜JAWS-UG in Nagoya〜 - よかろうもん！
10月6日に名古屋で開催された第4回JAWS-UGにて、「AWSを活用して少人数で複数のサービスを運用するコツ」というテーマで、SonicGardenの運用に関しての考え方や取り組みについてお話させていただきました。 当日の資料を以下から見えるようにしておきます。 「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜 また、資料のインプットとなっている記事については以下にリンクを用意しておきますので、時間があるときに読んでいただけましたら幸いです。 AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) - よかろうもん！ データやログのバックアップを楽に実現するために活用すべきライブラリ〜Backup〜 - よかろうもん！ 実践で使えるEBSスナップショット取得スクリプト - よかろうもん！ トータルフットボールなチームの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
