『家族アルバム みてね』を支えるオンコールエンジニア制度 | gihyo.jp
株式会社MIXIで『家族アルバム みてね』（以下みてね）のSREグループに所属している本間です。 みてねは現在、1,500万人を超えるユーザに175の国と地域でサービスを提供しています(2022年8月現在)。そこで、より高い信頼性と可用性を担保するためにみてねのSREグループではオンコールエンジニア制度を設けています。 今回はこの「みてねのSREグループにおけるオンコールエンジニア制度の取り組み」についてご紹介させて頂きます。 オンコールの定義 まず、どのような条件でアラートを設定しオンコールを実施するかの定義について簡単に触れておきます。 現在はさまざまなソースから多種多様な情報を収集することができます。 たとえば、みてねではKubernetes（Amazon EKS）を採用しています。Kubernetesだけでも非常に多くのメトリクスが収集できますが、それだけではなくアプリケーション
Google Cloud、暑さでダウンか ロンドンのデータセンターで冷却系に障害 Oracle Cloudも【復旧済み】
Google Cloudの欧州リージョンの一部（europe-west2）で障害が発生している。ロンドンにあるデータセンターの1つで、7月20日午前2時13分ごろ（日本時間、以下同）から、冷却関連のトラブルが起きているという。問題は一部改善しているものの、午前10時時点で解消はしていない。 障害によって、ユーザーが使う少数の仮想マシンが強制的に終了した他、スケーリングなどに影響が出たという。午前10時時点でも、一部のユーザーは仮想マシンの起動やスケーリングなどが通常通りできない場合がある。米Googleは引き続き改善に取り組むとしている。 同様の障害はOracle Cloudでも起きている。Oracle Cloudでは、19日午前12時21分ごろ、ロンドンにあるデータセンターで冷却系のトラブルが発生。一部ユーザーがサービスにアクセスしにくい状態になった。 米Oracleによれば、状態はすで
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
KDDIの通話・通信障害メモ - show log @yuyarin
この記事は7/3午前中に記載したもので、まだKDDI社長の会見内容を反映していません。 今回のKDDIの障害が具体的にどういうサービスに影響が出るのものか、モバイルネットワーク初心者としてLTE/EPC/IMS周りの挙動の勉強のためにまとめてみた。 はじめにまとめ モバイルの通信には音声通話とデータ通信があり、今回主に長時間の障害を受けたのは音声通話(IMS)の方だった。 7/2(土)の日中帯はデータ通信はできるが音声通話やそれに付属するサービスが利用できない状態が継続していた。データ通信も不安定な状態になっていた。 端末の実装(主にAndroid端末)によっては音声通話ができないとデータ通信も止めてしまう挙動があった。これによりLTEを回線として使用しAndroidベースで構築された決済システムなどが利用不可能な状態が継続した。 音声通話(IMS)が利用できないと、通常の電話はもちろん、
2022年6月21日に発生したCloudflareの大規模障害の原因 - Qiita
概要 今回は、2022年6月21日に発生したCloudflareの大規模障害についての原因がまとめられた記事が公開されたため、その内容について翻訳およびサマライズしていきます。 何が起こったのか 2022年6月21日にCloudflareの19のデータセンターのトラフィックに影響を与える障害が発生したようです。 また、この19のデータセンターはどうやら世界中のトラフィックのかなりの割合を扱う拠点だったようです。 ではなぜ、大規模な障害が発生したのかというと、原因はどうやらこれらの重要な拠点の耐障害性を向上させるための変更(ネットワーク設定の変更)を行なったことが起因しているようです。 なので、今回の障害では悪意のある攻撃等ではなかったことになります。 障害が発生した時刻と復旧した時刻 障害が発生した時刻は、2022年06月22日 15:58ごろに発生し、2022年06月22日 16:42ご
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「au通信障害」KDDI髙橋社長の会見質疑詳報、なにが起きたのか、「ドコモの教訓」は？
