フィーチャー開発から ホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~ @itohiro73 #開発生産性con_findy
![障害対応を楽しむ7つのコツ](https://cdn-ak-scissors.b.st-hatena.com/image/square/b9c43d84f05b7ca7da7c0e60387eedc2948b3274/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fe7e6529e5c0b4f38bf70076e62b43bf3%2Fslide_0.jpg%3F30804576)
フィーチャー開発から ホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~ @itohiro73 #開発生産性con_findy
株式会社KADOKAWA(本社:東京都千代田区、取締役 代表執行役社長 CEO:夏野剛)は、現在当社グループの複数のウェブサイトが利用できない事象が発生していることをお知らせいたします。この原因として、現時点では、当社グループが利用しているサーバーに対して、外部からの不正なアクセスが行われたことによる可能性が高いと分析しております。 お客様、お取引先様をはじめ、関係先の皆様に多大なるご心配とご迷惑をおかけし、深くお詫び申し上げます。 本件について、影響を最小限にとどめるべく、システムの保護と復旧に向けて、現在対応を進めております。現時点で判明している内容について、以下の通りご報告いたします。 1. 経緯 6月8日(土)未明より、当社グループの複数のサーバーにアクセスできない障害が発生しました。この事実を受け、データ保全のため関連するサーバーを至急シャットダウンしました。同日中に社内で分析調
2021年10月25日、この日は僕がただの大学生から、大学のサーバーをダウンさせた"犯人"へと変わった日です。 小説みたいな書き出しをしてみましたが、これは嘘みたいな本当の話で、ふと思い出して懐かしくなったので回想録として note に残すことにしました。 出来事の概要2年前の2021年10月、何が起きたかを簡単に書くと以下の通りです。 ・大学の授業や課題を管理するためのシステムを拡張するツールを作った ・ツールが予想以上の人数に使われ、結果として大学のサーバーに負荷がかかりサーバーが落ちる事態になった ・大学から呼び出しを受けることになった 時系列を追って、この note で出来事の全容を書きたいと思います。 使いづらい LMSまず前提として、私の大学では毎日の授業や課題は授業支援システム、通称 LMS と呼ばれるオンラインのシステムで管理されています。 実際のLMSの画面しかし、この
ネコをペットとして飼った経験がある人なら、PCでの作業中にネコがすり寄ってきた、という経験をしたことがあるはず。アメリカ・ミズーリ州カンザスシティの退役軍人医療センターでは、ネコがエンジニアのキーボードに飛び乗ったことで、サーバー情報が削除されてしまい、4時間にわたってシステムが停止したことが報告されています。 VA hospital's IT snafu blamed on cat's keyboard surfing • The Register https://www.theregister.com/2023/10/05/hospital_cat_incident/ 2023年9月中旬、カンザスシティ退役軍人医療センターでは、4時間にわたってシステムが停止する事例が発生。その後の約100人規模で行われた会議にて、エンジニアの一人が「サーバーのクラスタの構成を確認している際に、ペットの
JR東日本は6月26日、24日に発生した、モバイルSuicaでのチャージなどができなくなった障害について、電源工事のミスが原因だったと発表した。工事マニュアルに間違いがあり、計画と異なるブレーカーを切ってしまったことで、システムサーバへの電源供給が止まってしまったという。 原因は、屋内の電源工事。マニュアルには本来「盤NO6(CV6)内のブレーカーを『切』にする」と記載されるべきところ、「盤NO6(CV4)内のブレーカーを『切』にする」と書かれていた。 作業スタッフがこの誤りに気づかず、「盤NO4(CV4)」のブレーカーを切ったため、夜間処理中のシステムへの電源供給が止まり、ハード故障やデータ不整合が発生した。 障害発生から完全復旧まで約12時間かかった。サーバ電源を再投入し、ハードウェアの健全性を確認した後、電源供給停止時に実行されていた処理の再実行やデータの整合性を確認した上でサービス
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください! ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
4月3日の午前中に発生した「フレッツ光」と「ひかり電話」の障害ではNTT東日本、NTT西日本を合わせて最大約44万6000件に影響が出た。原因は新しい加入者装置に特殊なパケットが届いたこと。ただし「アタックである可能性は限りなく低い」としている。 障害が発生したのは午前7時10分ごろ。複数のNTT局舎内にある加入者収容装置が特殊なパケットを受信後にリブートした。フェイルオーバー機能が働き、自動的に別の装置に切り替わったものの、そちらも同じ障害が発生した。 NTT東では49拠点89台、NTT西は21拠点27台の加入者収容装置で同時に障害が発生し、ネット接続サービスの「フレッツ光」と光回線を使う電話サービス「ひかり電話」が一時つながりにくい状態になった。ひかり電話は緊急通報にも支障をきたし、消防庁が公式Twitterアカウントで「携帯電話や公衆電話の利用、消防への直接駆け込み」を促すツイートを
こんにちは。メディアサービス開発部Webアプリケーション開発課の奥川です。ニコニコ漫画のバックエンド開発を担当しています。 2021年初頭、ニコニコ漫画である作品の連載が開始されました。それに端を発する数カ月間のサーバ障害により、ユーザーの皆様には大変ご迷惑をおかけしました。 少し前の話にはなりますが、当時ニコニコ漫画のサーバでは何が起こっていたのか、どのような対応を行ったのかを振り返ってみたいと思います。 1号棟(事の起こり) 2021/01/08 問題の作品(以後、「作品I」*1と記述します)の第1話が投稿されます。その過激な内容からSNSなどでは一部で話題になりましたが、まだニコニコ漫画へのアクセスも穏やかなものでした。 2021/01/22 その2週間後、「第2話(前編)」の公開から事件が起こります。 ピークタイム最中の12:22頃から、まずmemcachedがCPU Utiliz
みずほフィナンシャルグループ(FG)は2021年10月8日、傘下のみずほ銀行で2021年8月以降に起こったシステム障害の詳細と、再発防止策の見直しに向けた課題認識を明らかにした。8月19~20日の「5度目」のシステム障害を巡っては、データセンター(DC)の切り替えという「奥の手」を使わなくても復旧させられたという見解を示した。 みずほ銀行に関しては、2021年に入ってから既に8件のシステム障害が表面化している。みずほFGが10月8日夕に開いた記者会見では、8月以降に発生したシステム障害の詳細を説明し、特に「5度目」の障害について時間を割いた。8月20日午前9時から午前9時45分まで、全463店舗で店頭取引ができなくなったという障害だ。午前11時58分まで融資や外国為替の一部取引も不能になった。 関連記事: みずほ銀行窓口業務ストップの真相、DC切り替えをためらい障害が長期化 「4000年に
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間(EC2) 約6時間 2019年8月23日 12時36分頃~18時30分頃(大部分の復旧) 障害発生時間(RDS) 約9時間半 2019年8月23日 12時36分頃~22時5分頃 障害原因(EC2) 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン(AP-NORTHEAST-1)の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊4データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
インフラエンジニアの世界 IT技術者というと世間から見たら、要件定義やシステム設計をおこなうシステムエンジニアと、それを実装するプログラマーしか見えてないと思うんですよね。でもその基盤を動かすインフラエンジニアという人たちが全体の10パーセント弱(肌感)存在しています。 インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。ネットワークエンジニアはスイッチやファイアウォール、ロードバランサーくらいまでは自分の領域としてくれていますが、OSやミドルウェアのことになると、それは私の領域ではない発言が出てサーバーエンジニアをブチ切れさせること請け合い。逆にネットワークエンジニアはサーバーエンジニアがなんでもネットワ
障害が起きたWebサービスは個人で運営しているサービスです。 2016年2月、障害から20日後にサービス再開しましたがアクティブユーザは以前の18%です。未だ回復の目処は立っていません。冗長化していないサーバがウイルス感染し、その後の対応も後手後手に回ってしまいました。 2016年1月末に起こるべくして起こった障害について記事にしてみました。ご迷惑をお掛けしてしまい本当に申し訳ありません。 ■ ユーザは、もう戻ってこない どんなウイルスに感染したのか SYNフラッド攻撃(SYN Flood Attack)を他のWebサイトに行うウイルスに感染して、確認していませんが他のサービスをSYNフラッド攻撃していたと思います。またウイルス感染時にサーバのsshdを書き換えられsshで接続できなくなりました。感染後にコンソールログインして書き換えられた醜い authorized_keys を見た時ゾッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く