オンコール対応とは？〜現場担当者が語るオンコール対応の不安解消方法を解説!～|インシデント管理プラットフォーム│PagerDuty
DevOpsの導入によって、開発エンジニアがサービスの信頼性と可用性に対する責任を負い、オンコール対応に携わるようになりました。オンコールは重要な職務ですが、精神的な負荷が大きいため不安を感じる方も多く、いわゆる「燃え尽き症候群」に陥る方も生じます。 そこで今回は、PagerDutyコミュニティのメンバーから寄せられた、オンコール対応の不安を取り除く方法や、オンコールローテーションに臨む際のアドバイスをご紹介します。ぜひ、今後の参考にしてください！ インシデント管理における「オンコール対応の重要性」オンコールとは、勤務時間外を含めて緊急対応が必要なインシデントに対応できるように、対応者や担当時間を決めておく仕組みです。 現在は、24時間365日稼働が前提となるシステムが多いなか、サービスの信頼性を守るには迅速なインシデント対応が求められます。仮にサービスが停止することになれば、機会喪失や顧
インシデントコマンダー業務解説～仕事の流れと必要な資質～|インシデント管理プラットフォーム│PagerDuty
前回は、何故インシデントコマンダーに注目が集まっているのか、そしてどのような役割なのかを解説しました（インシデントコマンダーとは？ 〜現代のIT運用には必須！その役割と理由〜）。今回はよりインシデントコマンダーの業務について踏み込んで解説を行っていきます。 おさらい: インシデントコマンダーとは 前回のおさらいをしましょう。インシデントコマンダーを一言で説明すると インシデントを解決に導く指揮官 です。重大なインシデントが発生した際、インシデント対応プロセスの全体を管理し、関係者間の調整とコミュニケーションを行い、出来る限り早くインシデントを解消に導くのが責務です。 インシデントコマンダーの役割 意思決定 作業担当への指示 作業要員や関連部署の招集・体制構築 ステークホルダーとのコミュニケーション 状況の交通整理 インシデントの発生と収束の宣言 ポストモーテムの作成指示 インシデント発生時
ゼロから始めるシステム障害対応フロー - Qiita
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
僕が障害復旧対応時に考えていることを言語化してみる - Qiita
これまで数多くのシステム障害を復旧してきました。 障害は無いに越したことは無いですし、起こらないように最善を尽くすのが我々エンジニアの使命です。 しかし、どれだけ最善を尽くしても起こる時には起こります。 今回は、これまで数多くの障害を復旧させてきたエンジニアが、復旧作業時に何を考えているのかを改めて言語化してみたいと思います。 こういう情報ってそれぞれのエンジニアの頭の中にあってあまり共有されないので、意外に参考になるかなと思います。 障害復旧対応の醍醐味 表現が適切かは分かりませんが、僕はシステム障害を復旧させるのが大好きです。目の前に起こっている事象からヒントを集め、地道に原因を切り分けてクリティカルヒットを見つけたときは名探偵になった爽快感があります。 加えて、動いているものを常に動かし続ける日頃の保守運用とは異なり、動いてないマイナスの状況を0まで戻すということで、復旧成功した際に
障害対応で大切だと感じていることのまとめ - Qiita
私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは
運用に携わる人全員に見てほしい！ Ops Guidesの紹介 - Qiita
PagerDuty Advent Calendarの8日目！ 今日はOps Guidesのお話です。 うちはこうだけど、他はどうやってるんだろう？ 普段から運用に関わっていると、ふとした瞬間に「そういえば他の会社ではどういう運用をやっているんだろう？」と気になること、ありませんか？ そのきっかけは「本当になんとなく」といったものから「上手くいかない運用にフラストレーションが溜まって」というどす黒いものまで色々あると思いますが、いずれにせよ「他の会社の良いところを取り入れて、自分たちの運用を改善したい」という気持ちから来ているのは間違いないでしょう。 だからこそ、いろんなミートアップに参加して発表を聞いたり、懇親会で話してみたり、Xに垂れ流されているいろんなポストを読んで事例を学ぶわけです。 ベストプラクティスを学びたい! このような取り組みはとても良いことですし、是非とも継続して情報収集し
限られた人数で MIXI のあらゆる公式サイト群を保守・運用する ノウハウとその体制 | MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜
2023年10月31日に株式会社MIXIで行われた「MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜」での発表資料です。 イベントページ https://mixi.connpass.com/event/299121/ ─────────────── MIXIのSREは、サービスの信頼性に直接関わる負荷やコスト、システムの信頼性などをサービス開発と密接に連携しながら取り組むようなSREと、社内の共通課題やスポットで相談された事業などへの技術支援など、全社的なサービスの信頼性に関わるありとあらゆることに取り組むSREがいます。 本イベントでは、後者の全社的なサービスの信頼性に関わるSREから、最近の取り組み事例を紹介させていただき、Q&Aの時間などを通して、ご参加の皆様と共に情報交換ができれば幸いです。 ◎こんな方におすすめ◎ ・SREとしてサイト信頼性だけでなく、企画や事業開発な
RaspberryPi を安定運用させる - Qiita
はじめに しまねソフト研究開発センター（略称 ITOC）にいます、東です。 教育用ワンボードマイコンとして販売されている Raspberry Pi （以下ラズパイ）は、教育用のみならず実験用、産業用とさまざまな分野で使われつつあります。一方、マイクロSDカードをメインストレージに使用している事や、OSがクライアントPCよりの設定にしてある事などから、長期安定運用には向かない面も存在します。 このレポートでは、OSや稼働させるソフトウェアの設定など、できるだけ簡易に再現可能な方法により、可能な限りラズパイを安定して長期運用させることを狙います。また、その題材として、デジタルサイネージ(*)を作ってみます。 私は、2000年ごろからフラッシュメモリを使ったFA機器の開発を皮切りに、10年ほど前からは民生用フラッシュメモリ（CF,SD,USBメモリ）を起動デバイスとした機器を開発・運用していまし
2年間の開発者ブログ運営のノウハウや意識してること - NTT Communications Engineers' Blog
みなさんこんにちは、イノベーションセンターの @Mahito です。普段は社内のエンジニアが働きやすくなることを目標に、コーポレートエンジニアとしての活動やエンジニア向けイベントの企画・運営をしています。 今回は、本 NTT Communications Engineers' Blog を2年間運営してきたノウハウについて共有できればと思います。先日 はてなブログ DevBlog Meetup #1 に登壇させていただく機会があり、ブログ運営に関していくつかお話しさせていただいたのですが、イベント当日に言えなかったことや言ったことの補足などをできればと思います。 目次 目次 開発者ブログのこれまでと目的 運用のノウハウ・意識していること 執筆者の確保・継続・インセンティブ設計 1. 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう 2. ニュースリリースを見て、技
サーバ監視品質担保のための夜勤シフトの仕事
はじめまして。MSPグループの夜勤チームのいかろちゃんです。 夜勤チームには特有の仕事がいくつかあります。 その中のひとつが各サーバにおける監視状況や通知設定が適切な状態にあるかをチェックするという仕事です。 今回はそれについて特にどういう部分を自動化していて、どうやって運用しているのかを紹介します。 はじめに サーバ監視業務を行ううえで不要なアラートを抑制することは重要です。アラートを抑制しないと大量のアラートに埋もれてしまったり、あるいはアラート通知が「どうせ対応不要のアラートだからいいや」など本当に重要なアラートを見逃してしまう可能性が上がってしまうためです。不要なアラートとして比較的多く見られるものは計画したメンテナンスや作業によるアラートが挙げられます。 ハートビーツ作業やお客様によるメンテナンスの際に一時的に監視通知の停止（以下、通知停止）や監視チェック実行の停止（以下、監視停
障害対応プロセスを改善してきた話 - 10X Product Blog
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
GoogleフォームとGASを使って利便性高くセキュアな共有ドライブ運用を作る
注意事項 かなり高度なGASの使い方なのである程度GWS（Googleフォームやスプレッドシート）やGASをわかってる方前提で書いていますので結構省略しているとこも多いです。 あと作った後に手順を書いているのでなにか抜け漏れあったらごめんなさい。 まだ作ってみただけで実際に運用はしてないのでテスト等も不十分かも。運用してからまた追記します。 コードは直接スクリプトエディタでサクッと作ったサンプルです、実際はローカルでLintかけたりするのでインデントおかしかったりしても許してください。 背景 GWSを使う際にマイドライブで外部共有可能にするとやりたい放題なのでセキュアな環境とは言い難くなる。 また組織のファイルをマイドライブにおいてしまうとファイルオーナーが退職したときの扱いに困る。上長に移管したり、退職者アカウントに移管するのが一般的かと思うが、移管するということはマイドライブのファイル
忘れ去られたドメイン名に宿る付喪神 | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 そんな情報を社内に留めておくのはもったいない！ということで、IIJ Engineers Blog編集部より、選りすぐりの情報をお届けします。 今回は、使わなくなったドメイン名はどのようにすればよいかを紹介します。 そのまま放置しておいてよいのか？（ダメ） 廃止すればよいのか？（もっとダメ） どういった対応を行えばよいのか？ どうぞご覧ください。 終わったサービス・キャンペーンのドメイン名、放置されていませんか？ ドメイン名を放置すると付喪神がやどり、ひとりでにサイトを公開したりメールを出し始め
30分でわかるシステム運用アンチパターン / Operations Anti Patterns in 30 minutes
「システム運用アンチパターン - Forkwell Library #4」でお話しした際の資料となります。 https://forkwell.connpass.com/event/256481/ 動画はこちら。 https://youtu.be/hQAeMgXsZWc
緊急性が高い障害対策の専門チームで学んだ、緊急案件対応の傾向と対策
以前、マイクロソフトのサポート部門で緊急性が高い障害対応の専門チームとして活動していた時期がありました。その時の経験から、緊急案件の対応方法についてまとめてみました。 「緊急性が高い障害」とは具体的にどのようなケースか？ 緊急案件として対応を依頼されるケースとしては、以下のようなパターンが多いと思います。 停止することで日々の業務オペレーションに甚大な影響を与える社内システム。例えばメールや商品の受発注など。 停止することで社会的な影響が大きいシステム。例えば社会インフラ、医療系など。 停止することで売り上げのロスに直接影響するシステム。例えばオンラインショップなどの E コマース。 こういった緊急案件では数時間以内での解決を求められます。よくある目安としては、障害発生から 2 ～ 4 時間以内に解決することを目標として対応することが多いように思います。 緊急案件対応のゴールとは何か？ 緊
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
運用自動化、不都合な真実 // Speaker Deck
https://twitter.com/badassceo/status/1741257575759589408
2023年12月5日に発生した複数AWSアカウントが操作不能となった障害について | クラスメソッド株式会社
問い合わせ率が3年間で半分になった
バンドルカードの クレジットカード決済システムの 泥臭い運用
