タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター
システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパンAmazon ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。 役割分担の基本 「入門 監視」に
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。 - MonotaRO Tech Blog
序文 こんにちは。MonotaROの伊藤です。 弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います 序文 運用担当者の負荷が高まり続ける問題 運用担当者=社歴が長いベテランエンジニア 運用のスケールアウト 障害対応訓練をやってみよう 訓練環境の準備の問題 訓練シナリオの問題 外部からの助け Wheel of Misfortuneとは 実施時の様子 シナリオ開始時の様子 モニタリング画面の表示 WoMとDiRT(Disaster in Recovery Training) 障害対応訓練をやってみた結果 準備時点で感じたメリット 手順書の不備を発見できたこと 障害が起こりかねない場所を考えるきっかけになったこと
Webアプリケーションの障害対応について改めて意識すべき点ややれると良いことをまとめる - stefafafan の fa は3つです
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
障害対応を楽しむ7つのコツ
Amazon S3 Vectorsは大規模ベクトル検索を低コスト化するサーバーレスなベクトルデータベースだ #jawsugsaga / S3 Vectors As A Serverless Vector Database
障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 | レバテックラボ（レバテックLAB）
TOPインタビュー障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 2024年8月26日 ユーザベース NewsPicks事業 SREチームリーダー 安藤 裕紀 大手SIerで10年半エンジニア/アーキテクトとしてアプリケーション開発、インフラ構築、クラウド活用コンサルティングなど大企業の技術支援を行った後、2021年10月に株式会社ユーザベースに入社。プロダクト開発組織のSREチームでインフラや開発基盤を担当。シニアエンジニア、テックリードを経て、チームリーダーに。2024年からはプラットフォームエンジニアリングのグループマネージャーも兼務。 X Docswell GitHub
ChatGPT上で障害対応をシミュレートする
長年やろうやろうと思ってできていないことの一つに、障害対応訓練がある。 今回はその訓練をChatGPT上でやってみたという話。 もちろん、Claudeなどの他の対話型生成AIサービスでもできるはず。 障害対応は実際にやらないとできるようにならない #Webサービスなどのシステムを運用している場合、避けては通れないものとして 障害 がある。 負荷の増加やシステムの変更、オペレーションミスなどで発生するこれらの障害は、 程度にもよるが少なからずシステムの運用に支障をきたすため、迅速に解消する必要がある。 いわゆる 「障害対応」 である。 障害発生時には、まず何が起こっているのかを把握する必要がある。 各種ログやメトリクスから原因となっている箇所を特定し、解消・緩和するための変更を行う。 原因は場合によって様々で、アプリケーションの不具合であることもあるし、 ネットワークなどプラットフォームに近
Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805
失敗して攻め続けるために - freeeのエンジニアが障害対応で実践していること - freee Developers Hub
2015年10月入社でコアエンジンチームの@kompiroと申します。普段は下記の３つの業務に従事しています。 お客様が自社の情報を把握するためのデータアグリゲーション機能の開発 マイクロサービスに切り出したデータアグリゲーション機能をEKSに移行 チーム横断で開発者のみんなが開発しやすい環境の構築 そんな私ですが、最近しくじり開拓者のつどいという社内イベントを開催しています。これは障害対応の一環として始めたイベントです。今日はしくじり開拓者のつどいというイベントをみなさまに紹介するとともに、背景となる障害に対する考え方と障害対応の流れを解説します！ freeeの開発文化と障害対応 freeeの開発文化 こちら弊社の紹介スライドからの引用です。 freeeのエンジニアチームが大切にする開発文化が言語化されたものが 失敗して攻めよう 何でもやれる、何でもやる 必殺技 カッとしてシュッとやる
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
2024/11/15 AWS オンラインセミナー、「生成 AI が切り拓く、今後のエンジニアリング環境」での発表資料になります。 https://pages.awscloud.com/eib-aiml-241115-reg.html
障害対応時に AWS Direct Connect を手動で VPN へとフェイルオーバーする手法について - サーバーワークスエンジニアブログ
営業部 佐竹です。 本日は、2021年9月2日 の 午前7時30分から午後1時42分までの間に発生していた「東京リージョンにおけるダイレクトコネクト（専用線：以下 DX と記載）障害に関する記事となります。 はじめに 影響範囲について 一時的な対応策 DX をダウンさせる 1-1. CGW で NIC を Shutdown する 1-2. 物理線を抜く 1-3. DX フェイルオーバーテストの実行 2021年10月5日 追記 BGP 設定で対応する 2-1. 広報経路を更新する その他の手法 参考情報 Personal Health Dashboard の履歴1 [4:00 PM PDT] [4:45 PM PDT] [6:49 PM PDT] [6:49 PM PDT] [9:56 PM PDT] Personal Health Dashboard の履歴2 [05:39 PM PDT]
BASE社とnote社は、安定したサービス提供をするために、リアーキテクチャやフロントの刷新、セキュリティの強化、パフォーマンス改善など、さまざまな工夫を行っています。それぞれのCTOが課題に対する取り組みと組織運営での奮闘を赤裸々に語りました。2回目は、2020年に起きた障害と技術課題について両CTOが話しました。前回はこちら。 自分たちが想定したものはけっこう簡単に崩れてしまう 司会者：ありがとうございます。チャットを送ってくださったみなさんありがとうございます。ではさっそく、パネルトークに入っていきたいと思います。いくつかテーマを用意しているので、そちらをピックアップしながら話してもらおうと思っています。 今回、4つピックアップしているのですが、チャットで「これってどうなっているんですか？」みたいなものがあれば、適宜拾っていこうと思っています。チャットやQ&Aを送ってもらえるとうれし
加藤公一（はむかず） @hamukazu 「LTO（Linear Tape-Open）テープの持ち込みによって処理するようにした。」 キター！ xtech.nikkei.com/atcl/nxt/news/… 2023-10-11 21:17:52 加藤公一（はむかず） @hamukazu Kimikazu Kato, 博士（情報理工学）。修士は数学（代数幾何学）。英検三級。にゃーんと鳴く狂犬と呼ばれている。DMは全員に開放中。 著書「機械学習のエッセンス」：bit.ly/mlessence 、監修「機械学習図鑑」bit.ly/mlzukan linkedin.com/in/kimikazukato リンク 日経クロステック（xTECH） 全銀システムの大規模障害、中継コンピューター2台ともに不具合で冗長構成が機能せず 2023年10月10日午前8時30分ごろに発生した「全国銀行データ通信
障害対応の属人化から脱却。全員を巻き込む仕組みづくりの方法 (2024/12/17 19:00〜)
新機能 技術カンファレンスをより見つけやすく、参加しやすくするための新機能「カンファレンス特集ページ」をリリースしました。「技術」や「テーマ」などのトピック別に探せるほか、直近開催予定のカンファレンスが一覧で確認できますのでご活用ください。詳しい機能説明や掲載方法についてはこちらをご確認ください。 注意 現在、一部のブラウザ環境において、イベント参加画面の「申し込みを確定する」ボタンがグレーアウトしたままクリックできない現象が報告されています。ブラウザ拡張機能(Video Speed Controllerなど)の影響が考えられます。 お手数をおかけしますが、現象が発生した場合はお使いのブラウザの拡張機能を一時的に無効化するか、シークレットウィンドウでの操作をお試しください。 なお、connpassではブラウザの標準動作を変更する拡張機能を使用した環境での正常な動作は保証しておりませんので、
【ラクス】インフラ運用チームが障害対応時間削減に向けて取り組んだこと - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは。cappy_potterです。 MailDealer と ChatDeaeler という弊社サービスのインフラ運用チームのリーダを担当しています。 現状、これら2サービスで稼働しているサーバの数は、合計で1,000台近くありますが、 これだけサーバがあると、様々な障害も発生します。 中でも、仮想基盤機器やネットワーク機器で障害が発生した場合は、影響範囲が大きくなりやすいです。 主にそういったものに対し、「どうすればチームとして迅速に対応できるようになるか？」ということを考え、実践したことについて紹介したいと思います。 はじめに 過去発生した障害について 周知に時間がかかる要因 各要因への対策 要因①：各自バラバラに対応していて、ムダが生じている 要因②：周知を行う際の目標時間を定めていない 要因③：周知文に記載する内容を都度考えている 要因④：影響範囲特定に必要なアク
こんにちは！BASE株式会社 上級執行役員の藤川です。今年からTech DepartmentというBASE社の開発の成功や情報システム、セキュリティ等に責任を持つチームを運営しています。 システム障害はWebサービスを自社運用する企業にとって最重要な問題であり、サービス改善のきっかけになることも多々あります。ただ単に目の前の問題を場当たり的に解決するだけでなく、再現性を減らすために体制やシステム投資の見直しなどにもつながるきっかけになるものなので、そこで起きている本質的、潜在的な課題を見つけ出すことも障害対応の重要なミッションです。 また事件は現場で起きているわけで、障害要因となるものは、何もバグやシステム設定の不足や不備などに基づくものだけではありません。インターネットの世界が日常的に変化しているので、外乱としての障害要因も多々存在し、これらの問題と常に戦っています。 そういう不確実な状
Mackerel で行った障害対応演習を紹介します - Hatena Developer Blog
こんにちは、Mackerel チーム SRE の id:heleeen です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の4月号で、先月分は id:taxintt さんのサービスの一般公開前からSLI/SLOと向き合うです。 今回は、先日 Mackerel チームで行った障害対応演習で実施した内容と、どのような学びを得たかについて紹介します。 本番障害はできればなくしたいものですが、すべての障害を完全になくし可用性を100%にするのはとても困難です。そのため、障害が発生したときの影響範囲を小さくする仕組みを導入したり、ロールバックを素早く行えるようにしておくなど、影響を抑えるための取り組みが必要になります。 Mackerel では、その一環として、障害対応時のオペレーションの確認やバックアップからの復旧が行えるかの検証などの起きてしまった障害を素早く収束させたり、
エンタープライズ企業の障害対応革新 – PagerDuty導入とその成果/pagerduty-usecase-of-aeon
PagerDuty on Tour TOKYO 2024での発表資料です。 https://www.pagerduty.co.jp/pagerdutyontourtokyo/
こんにちは、ファインディ株式会社で機械学習エンジニアをしていますsasanoshouta(@Edyyyyon)です。この記事は、ファインディでインシデントが発生した際に行なっているポストモーテムの運用とその様子について、先日発生したインシデントを元に紹介をする記事となっています。 今回発生したインシデントについて まず、今回発生したインシデントについて軽く紹介をさせていただきます。一言で表現すると、サービスの機能の1つを一時的に停止させてしまいました。 ポストモーテムの様子 弊社ではインシデントが発生した際にポストモーテムを実施して再発防止に努めております。 ポストモーテムとは？ そもそもポストモーテムとはなんだ？と言う方もおられるかもしれませんので、簡単にご紹介いたします。 ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデ
Cybozu における次世代障害対応研修の計画と実践 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！SREチーム兼Manekiチームのhsnとaoi1です。今回サイボウズでの障害対応研修の紹介をします。 背景 cybozu.comでは現在2つの運用基盤が存在しています。 Forest と呼ばれている旧インフラ基盤と、2019年に運用を開始した Kubernetes をベースにした Neco と呼ばれている新基盤です。 Forest 基盤で動いているサービスを Neco 基盤に移すと同時に、サービスの運用体制を見直す機会に直面しています。これを担当しているのが我々Manekiチームです。 Forest 基盤の仕組み上、ほとんどの障害対応は Forest 基盤を運用する SRE チームにしかできなかったため、製品開発チーム（以下：開発チーム）と運用チームが完全に分れていました。 しかしこのチーム体制はコミュニケーションに時間がかかる、製品開発チームが自分たちの開発物をコントロール
CrowdStrikeが大規模障害対応のおわびにUber Eatsのギフト券10ドル分をパートナー企業やエンジニアに配布
by Wil C. Fry セキュリティソフトのアップデートエラーにより、世界で850万台のWindows PCがブルースクリーンを繰り返す大規模なインシデントを引き起こしてしまったCrowdStrikeが、謝罪としてパートナー企業やエンジニアにUber Eatsのギフト券10ドル(約1530円)分を配布していると、IT系ニュースサイトのTechCrunchが報じています。 CrowdStrike offers a $10 apology gift card to say sorry for outage | TechCrunch https://techcrunch.com/2024/07/24/crowdstrike-offers-a-10-apology-gift-card-to-say-sorry-for-outage/ CrowdStrike offers $10 Uber Ea
「こんな僕でも結婚できました」の内容がなかなか凄い→「20代で禿げていた」「デートドタキャンの理由が障害対応」「彼女の年収を超えたことがない」
無能なボンブ@ITエンジニアのまとめ @itengr_matome 経歴だけ無駄に長い、ほぼ何もできない自営業のITエンジニアです。自分への戒めにごく稀に辛辣なツイートをします。独身の方、お仕事・プライベートに悩んでいる方、短気な方はご注意ください。X（Twitter）のみんなは、ITエンジニアのいいところをXeetしてますが、ボンブは現実をXeetします。 itenginner-matome.net 無能なボンブ@ITエンジニアのまとめ @itengr_matome 結婚できない理由はないと思うのは下記の理由からです 20代で禿げていた 彼女の年収を超えたことがない 最高賞与が彼女の最低賞与を下回っていた デートの90%が秋葉原経由 デートドタキャンの理由が100%で障害対応 週に3回ほど深夜障害連絡で叩き起こされる（同棲時） こんな僕でも結婚できました 2023-08-11 20:16
【ラクス】インフラ運用チームが障害対応時間削減に向けて取り組んだ、その後について - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちわ。cappy_potterです。 MailDealer と ChatDeaeler という弊社サービスのインフラ運用チームのリーダを担当しています。 前回、こちらの記事で、『チームとして障害対応時間削減に向けて取り組んだこと』について 紹介させていただきました。 tech-blog.rakus.co.jp その際、記事の中で、取り組み実施後に同様の障害が発生したことについて触れ、取り組み実施前に比べて 関係者への情報共有の時間をおよそ半分にできたと記載しました。 （以前は同様の障害で「42分」かかっていたものが、「22分」に短縮できた。） あれからさらに半年が経過したところで、再度大きな障害が発生したのですが、今回については 効果的に動くことができず、サービス復旧までに多大な時間を要してしまいました。 （関係者への情報共有についても、障害発生から「30分」かかってしまい
こんにちは。テクニカルサポートチームのShiinaです。 はじめに Datadog の監視データを、自然言語で簡単に扱える時代が到来しました。 注目を集めている MCP と Claude Desktop を組み合わせることで、専門知識がなくても分析が可能になります。 本記事では、その導入手順と活用例をご紹介します。 利用する Datadog MCP Server 今回、こちらの MCP Server を利用しました。 前提 Datadog API キーを発行していること Datadog アプリケーションキー（APPキー）を発行していること Claude Desktop がインストールされていること Claude Desktop 設定手順 下記の json 形式の設定ファイルに MCP サーバーの定義を追加します。 MacOS: ~/Library/Application Support/C
プロダクトエンジニアリング部の吉田と申します。 普段はRubyやTypeScriptといった言語を使ったサーバサイドエンジニアをしています。 今回、サイトの閲覧障害をきっかけに行ったポストモーテム会が個人的にとても有意義だと感じたので紹介させてください。 障害分析レポートの紹介 弊社では障害が起きた場合、障害分析レポートを書くという決まりがあります。 この障害分析レポートというものは、一般的にはSREの用語でポストモーテムとして知られている障害対応時のことを記録する文書のことです。 弊社では品質管理を行っている部署がテンプレートやフォーマットを整えてくれており、内容としてはオライリーのSRE本の付録Dに記載してある「ポストモーテムの例」にかなり似通った内容です。 かいつまんで紹介すると下記のような内容を記載するものです。 障害の概要 影響範囲 タイムライン 水面下で起きていた問題（根本の問
システム障害対応に指揮官(インシデントコマンダー)として関わる際にやっている事 11 個 - エス・エム・エス エンジニア テックブログ
この記事は 株式会社エス・エム・エス Advent Calendar 2023 の11日目の記事です。 無いに越した事はありませんが、サービスを長い間運用しているとどうしてもシステム障害対応をやらなければいけないタイミングがあります。この記事では、小規模なアラート対応から数日間に渡るチーム横断での大規模障害までいくつのシステム障害対応に関わる中で実際に私が行ってきた事を 11 個紹介してみようと思います。 前置きとして、現在私が所属するチームはほぼ100%フルリモートで開発を行っており、それを前提とした内容になっています。 1. 専用のコミュニケーションスペースを作る 2. 役割分担をする 3. 積極的に音声通話でやりとりする 4. 情報整理用のダッシュボードを作る 5. 専用のカンバンを作る 6. 情報同期のための定時ミーティングを設ける 7. 通常業務を進めるメンバーを残す 8. メト
このドキュメントはインシデント発生前に予防として読んでおくことを想定しています。 緊急時は <�骪 及び �Dꪪ を確認してください。 インシデント対応について P� ꪪ がより網羅的かつ真とするドキュメントです。 このドキュメントでは上記のドキュメントの内容を補足する内容として特に new joiner が認識しておくべき情報を抽出/加筆したものです。 もし上のドキュメントとこの章に食い違いが生じる場合は上のドキュメントを真としてこの章を編集してください。 各チームで new joiner を受け入れるときにこのドキュメントを一律に共有することで共通認識を得ることを目的にします。 このため主に障害対応経験が少ない人に向けた最低限の心構えを共有するものであり障害対応に関する情報を網羅的にまとめたものではありません。 障害対応経験者は障害対応を誰かに任せる場合にはこのドキュメントの内容を把
「障害対応」と聞くと、なんだか怖そうなイメージがあるかもしれません。 初めての障害対応を経験して、「もう二度とやりたくない」と思った人もいるかもしれません。 ですが、大丈夫です。障害対応は決して「怖いもの」ではないし、「一人で戦うもの」でもありません。 むしろ、エンジニアが成長するための大切な機会です。 この記事では、障害対応にどう向き合えばいいかをお伝えします。 障害対応は怖いものではない最初に伝えたいこと：「怖がらなくていい」「自分のせいで障害が起きたらどうしよう…」と不安になるかもしれません。 ですが、障害対応はエンジニアなら誰もが経験するものです。 エンジニアの仕事は「ミスをしないこと」ではなく、「起きた問題をどう乗り越えるか」にあります。 そして、多くの場合、障害対応はチームで行うものです。一人で全部抱え込む必要はありません。 「怖い」と感じるのは真剣だからもし「障害対応が怖い」
OOMしたCronJobのメモリ制限を「いい感じ」に増やし、不必要な課金・障害対応を減らす - エムスリーテックブログ
初めまして、2024年3月後半にエムスリーのAI・機械学習チームで10日間インターンに参加させていただいた東（@azuma_alvin）です。 もしタイトルが何かに似ていると感じた方がいれば、只者ではないと思われます。 洗練されたデザインでかっこいいと思ったエムスリーオフィスの受付の写真 この記事では、KubernetesのCronJobでOOM（Out Of Memory）が発生した時に「いい感じ」にメモリ制限を増加させてくれるbroomの開発経緯とその実装についてお話しします。 また、インターン期間で感じたエムスリーという「ギーク集団」の中で開発する楽しさについてもお伝えできればと思います。 2週間でゼロ（nil）から開発したbroomは、OSSとしてGitHubで公開しているのでコントリビュートお待ちしております！ github.com CronJobのOOMとは CronJobのO
マネジメントはシミュレーションゲーム、Rubyのお気に入りポイント、仕事だと障害対応が一番楽しい【Rubyistめぐりvol.5 onkさん 後編】 - STORES Product Blog
Rubyist Hotlinksにインスパイアされて始まったイベント『Rubyistめぐり』。第5回はonkさんをゲストに迎えて、お話を聞きました。こちらは後編です。（前編はこちら） hey.connpass.com 最先端で障害対応ができる自負がある 藤村：最近はどんなことしてるんですか？ onk：最近はマネージャーをやっております。仕事では手を動かしてないですね。 藤村：主な関心ごと、主な時間を使っているところってどういうことですか？ onk：定例ミーティングと1on1でほぼ全ての時間が消えていくので、主な関心ごとは見ている全てのプロジェクトが破綻しないことですね。カレンダーがテトリスになってます。しかももうほぼゲームオーバー寸前のテトリス。 藤村：ここらへんも似てるからまた話が広がらない、わかるで終わっちゃうのが悲しいところなんですけど。時間の確保とかどうしてます？普通にやっていると
みずほ障害、対応の遅れで不正引き出しも 金融庁にきょう報告
みずほ銀行で今月起きた今年５回目のシステム障害を巡り、みずほフィナンシャルグループは３１日、金融庁に報告書を提出する。故障の要因やバックアップに切り替わらなかった原因は特定できなかった。写真は、みずほのロゴ。２０１５年５月１５日に都内で撮影。（２０２１年 ロイター／Yuya Shino） ［東京 ３１日 ロイター］ - みずほ銀行で今月起きたシステム障害の影響で、キャッシュカードの紛失登録が遅れ、５０万円が不正に引き出されたことが分かった。みずほフィナンシャルグループは３１日にシステム障害に関する報告書を金融庁に提出する。故障の要因やバックアップに切り替わらなかった原因は特定できなかった。 金融庁は５回目の障害を受け、銀行法に基づく報告命令を出した。麻生太郎金融担当相は３１日の閣議後会見で、個別の金融機関にどのような行政対応を行うかの具体的なコメントは現時点で差し控えるとしつつ、報告内容を
全銀ネットでは、障害発生直前の10月7～9日に、全銀システムと金融機関の接続を中継するリレーコンピューター（RC）の更改作業を行った。NTTデータは全銀システムに携わっており、旧RC（RC17シリーズ）を新RC（RC23シリーズ）に更改するプロジェクトを担当している。更改は、金融機関で設置、稼働するRC17シリーズをRC23シリーズに更新した上で、稼働環境を全銀システムに集約するものとなる。 全銀ネットの10月18日の発表によると、障害はRCで処理する金融機関の送金／着金の手数料に関連した「内国為替制度運営費」で発生した。ここでの処理方法の1つに「あらかじめRCに設定されたテーブルを参照してRCが電文に金額を入力」があり、その処理にエラーが発生してRCが異常終了し、電文の送受信に影響が生じた。 NTTデータの説明によると、障害の直接的な原因は、上記の「あらかじめRCに設定されたテーブル」を
障害対応をがんばるPMは尊い｜さとじゅん
メルペイでPMしてます、さとじゅんです。 言いたいことはタイトルの通りです。 「障害対応がんばるPMは尊い！！！！！！！！」」 現場からは以上です。 ありがとうございました。 、、、と言うくらい、タイトルでもう言いたいことの80%くらいを言い切ってしまいました。 ちなみに最初に言っておきますが、障害対応自体はPMだけでなく関わった方すべてが尊いです。 これは間違いありません。 今回はPMに焦点をあてた内容にしたかったのでこのタイトルにしました。 障害が起きた時、とてもプレッシャーのかかる局面だったかと思います。 なにが起きてるのかわからず焦ってしまったと思います。 それでも仲間と乗り越えてきたんだと思います。 みなさま本当にいつもお疲れさまでございます。 まえおきということで、プロダクトを運用していく過程で障害対応は避けては通れないですよね。 昨今の華々しいプロダクトマネジメント論はプロダ
23年3月期上半期の売上高は2兆7408億円（前年同期比4.4％増）、営業利益は5585億円（前年同期比2.5％減）。利益の増減要因を見ると、通信障害と燃料高騰の影響を除けば営業利益は5733億円になるはずだった。 「通信障害と燃料高騰はさすがにわれわれも予期できなかった。（利益に）影響は出ると思うが、引き続き増益にこだわって進めていく」 KDDIの高橋誠社長は発表会でそう話した。同社は技術部、営業部、広報部などさまざまな部門を横断して「通信基盤強化ならびにお客さま対応強化対策会議」を組織。作業品質・運用・設備・お客さま対応の4観点でワーキンググループを設けて通信障害に対する検証と対応を進めているという。 同社は同日、総務省に通信障害に関する報告書を提出。再発防止策として（1）作業手順やリスク評価などの基準の見直し（2）輻輳（ふくそう）検知ツールの開発やシステム構成の見直し（3）輻輳解消ツ
【登壇】YAPC::Kyoto 2023で障害対応について登壇してきた #yapcjapan - 地方エンジニアの学習日記
yapcjapan.org YAPC::Kyoto 2023で登壇してきました！これまでオフラインイベントで登壇といえば少人数でのイベントくらいでこの規模で話すのは初だったので緊張してましたが始まってしまえばとても楽しめて話せてとても良い機会になりました！ありがとうございます！ほぼ満席(多分)で発表後の質問やTwitterでも反響があってとても嬉しかったです。トレーニングなどのコスト周りの内容はもう少し補足が必要だったなと思ったのでブログなり資料修正をして追記しようかなと思います。 speakerdeck.com セッションもとても刺さるものが多くて学びや今後のやる気に繋がるものが多くてよかったです。(詳細については会社のテックブログに記載しようかなと思います。)。懇親会ではネットの向こう側だった方と多く話す機会を得ることができ場を作って頂いたHelpfeelさんにはとても感謝です。 その
4月に発生したETCの大規模なシステム障害をめぐり、中日本高速道路は利用料金をめぐる対応に一貫性がなく、混乱を招いたなどとして国土交通省から厳重注意を受けました。 4月6日から7日にかけて発生したETCの大規模なシステム障害では、東京や愛知など、8都県の106か所の料金所などでETCレーンが通行できなくなり、中日本高速道路は、出口のバーを開放して、そのまま通行してもらう対応をとりました。 その際の料金について、会社は当初、後日の精算を呼びかけていましたが、5月2日に一転して、料金は請求しない方針を明らかにしました。 これについて中日本高速道路の縄田正社長は、5月7日に国土交通省を訪れて、中野国土交通大臣と面会しました。 その後、記者団に対し、会社としての対応に一貫性がなく混乱を招いたなどとして、厳重注意を受けたことを明らかにしました。 また、すでに料金を支払った利用者などへの還元を丁寧に行
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
入門監視やSRE本に学ぶ障害対応フォーメーション - An Epicurean
障害対応で大切だと感じていることのまとめ - Qiita
障害対応プロセスを改善してきた話 - 10X Product Blog
効果的なオンコール対応と障害対応
ゼロから始めるシステム障害対応フロー - Qiita
想定していたものはけっこう簡単に崩れる BASEとnoteのCTOが、発生した障害対応で実感したこと
全銀システムの障害対応で『LTOテープでデータ転送』伝説の年寄り出てきたみたいなアツさがある「訓練あるよね」
マルチステークホルダー時代の障害対応フロー - BASEプロダクトチームブログ
障害対応におけるポストモーテムのご紹介 - Findy Tech Blog
Datadog MCP サーバで自然言語分析＆障害対応をやってみた | DevelopersIO
ポストモーテム会を行って障害対応の改善を図った話 - LIFULL Creators Blog
障害対応の心構え | Wantedly Engineering Handbook
エンジニアの障害対応に対する向き合い方（初級編）｜くま｜Kuma Base代表
NTTデータ、全銀ネットの障害対応を説明--根本原因にめども「包括的な点検が必要」
木原官房副長官、KDDIの障害対応めぐり「周知・広報に責任を果たしたといえない」
微増益になるはずが──KDDI、障害対応・燃料高騰で約150億円消える 今後の対策にも500億円
ETCシステム障害 対応に一貫性なし 中日本高速道路 厳重注意 | NHK
recruit-it-remote-works.com
recruit-it-remote-works.com
www.pekepekepeke.com
www.freem.ne.jp
www.nikkei.com
www.smartnews.com