立川市役所の庁内LAN障害、原因は「Edgeブラウザーへの移行」
2022年6月27日、東京・立川市役所で大規模な通信障害が発生した。出先機関を含めた1000台以上のパソコンで終日、窓口作業ができなくなった。庁内LANの心臓部となるコアスイッチの障害が原因だった。コアスイッチに向けて大量の通信が発生し、メモリー不足に陥った。原因特定に時間がかかり、完全復旧に1週間を要した。 グループウエアの挙動がどうもおかしい――。東京都立川市役所の本庁舎内がざわつき始めたのは2022年6月27日、始業時刻である午前8時半ごろのことだ。ほどなく市役所のITインフラストラクチャー運営を担う総合政策部情報推進課のもとに、「窓口業務用の情報システムにアクセスしづらい」「内線電話が通じなくなった」といった職員らの困惑した声が続々と寄せられるようになった。 情報推進課はただちに障害箇所の特定に乗り出した。庁内ネットワークのメンテナンスを委託している保守事業者と連絡を取り合い、担当
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
何それつらい、オラクル「自社データセンターを作ったので引っ越ししてください」、客「何ですと？」 - orangeitems’s diary
これは大変な話 そりゃあ、インフラ担当者は頭を抱えてるでしょうなあ。 japan.zdnet.com 米Oracleおよび日本オラクル（以下、オラクル）は、国内で自社運営のデータセンター（以下、DC）を間もなく開設するのに伴い、富士通の国内DC内に設置しているクラウドサービス「Oracle Cloud」を利用する顧客企業に対し、自社DCへ移行するように交渉を進めていることが、関係者の話で分かった。 （中略） 両社にとっては今回の移行に際して、とにかく顧客企業の継続したクラウド利用にトラブルがないように実施することが求められる。顧客企業側もそれなりに労力を使うため、思わずため息をつきたくなるようだ。間借りは解消しても、両社の協業によるサービス品質はむしろ向上したと、顧客企業が感じるように努めてもらいたい。 データセンターなんてよほどのことが無ければ永劫に使えると思って契約しますよね。5年後無
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 - ＠IT
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した
「世界最悪のログイン処理コード」を解説してみた
概要 ところでこのツイートを見てほしい。このソースコードをどう思う？ 世界最悪のログイン処理コード。 実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn — はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日 すごく……セキュリティーホールです…… 一応は動いていますが、あまりに問題がありすぎるため、Twitterでも話題になっていました。 問題点は片手に入り切らないぐらいある気がしますが、一つづつ解説していきます。 ※元記事のタイトルに記載されていますが、このコードはイントラネット内で動作していたものです。 問題点リスト 1. クライアント上のJavaScriptで書かれている 他の問題点を全部ぶっ飛ばすぐらいの重大な不具合です。 クライアントと言うのはこの場合、
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 ファーストサーバが提供しているホスティングサービス「Zenlogic」は、6月下旬から断続的に生じていたストレージ障害に対応するためのメンテナンスが終了の見通しも立たないほど難航し、結局、メンテナンス開始から3日後の夜にようやくサービスが再開されるという事象を起こしました。 参考：ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり） － Publickey サービス再開から約1週間が経過した7月17日、同社はストレージ障害に関する原因およびメンテナンスによるサービス停止が長期化してしまった原因、再発防止策についての報告書を明らかにしました。 報告によると、ストレージ障害の直
Slack、全ユーザーが接続できなくなった大規模障害の原因はバッチ処理にバグがあったためと報告
チャットサービスを提供するSlackは、太平洋夏時間の6月27日午前6時30分（日本時間6月27日午後10時30分）頃から約3時間、全てのユーザーでSlackが利用できなくなる深刻な障害に見舞われました。 同社はその後、障害についての報告をステータスページに掲載。障害の原因が、データのバッチ処理に含まれていたバグであったことを明らかにしました。 同社の報告の一部を引用します。 On June 27th (yesterday) between 6:33 a.m. and 9:49 a.m. PDT Slack experienced an outage where people could not connect to their workspaces. The network problems were caused by a bug included in an offline batc
メルカリの3つのValueで取り組むインシデント対応 | メルカリエンジニアリング
TL;DR こんにちは、SRE の @masartzです。 メルカリには Go Bold、 Be Professional、All for One という3つの行動指針（Value）があります。今回はこれらのValueを元にメルカリでインシデント対応をどのように行っているかを紹介します。 インシデント対応とは 本エントリでは、いわゆるハードウェアやネットワークなどのインフラにおける不具合や故障だけでなく、プロダクトひいては会社活動全般における非日常的な状況に対する対応をインシデントと定義して進めます。 何をやっているか インシデント対応は、障害の発生から根本解決までの過程で大きく2つの段階に分けられます。 障害発生から一旦の収束まで 発生した障害を監視システムなどで検知します あらかじめ用意された専用のSlackチャンネルに共有し、対応を開始します 状況の把握と早期の復旧に務めます 機能の
マクロで作業工程を改善するのは大歓迎なのですが、無断でやるのは避けた方がいいです。
仕事関係の割とステレオタイプな寓話として、「Excelでマクロを組んで業務効率化したのに何故か怒られた」というものがあります。 皆さん、そういう話読んだことありますか？ webでパッと検索してみると、幾つか類型的なものが引っかかります。これなんか結構昔からあるヤツですね。タイムスタンプは2009年になっています。 K谷「ああ、自動で計算するﾌﾟﾛｸﾞﾗﾑを組んだんですよ、ﾏｸﾛって言います。 こっちでやった方が作業効率も上がるしミスも減ると思いまして、何か問題だったでしょうか？」 ・・・・・・・・・・はぁ！？会社舐めるのもいい加減にしろよ、 仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかということ、 そんなの社会人としてというか人として当たり前のことです。 マラソン大会で一人だけ車を使って優勝してもそんなの評価されていいわけがない。 「yahoo釣り袋」などと揶揄
【続】元給食営業マンが話題の「マズい」学校給食を考察してみた。 - Everything you've ever Dreamed
神奈川県大磯町の中学校給食がそのマズさと、異常な残食率と、異物混入件数とでニュースになっているのを受けて先日このような記事を書いた。 元給食営業マンが話題の「マズい」学校給食を考察してみた。 - Everything you've ever Dreamed 書いた理由は「委託や給食やデリバリー方式が悪い」という片寄った報道が多すぎて「いや委託側にも非はあるよ」と、大磯町と近い湘南エリアの元給食業界にいた者として言い返したかったからだ。そういう意図で書かれていたので、なぜ、当該受託業者に決まったのかと、導入プランの拙さについてはほとんど触れていなかった。その点を補足するのがこの文章の狙いである。なので補足なので先の記事を読んでからにして欲しい。先の記事で、僕はこの大磯の事態の大きな原因として「条件の悪さ」を挙げた。特に業務委託料（総額134,224千円【580日分】／1日当たり231,420
システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel お知らせ #mackerelio
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
ネット通じ水門の管理など行う自治体のシステムに深刻な不備 | NHKニュース
災害に備えるためインターネットを通じて川の水位を監視したり水門を管理したりする全国の自治体の５０余りのシステムに、機能を停止させられたり遠隔操作されたりするおそれがあるなど、深刻な不備があったことが、国のセキュリティー専門機関の調査でわかりました。インターネットにつながった防災機器の管理のもろさを浮き彫りにしています。 こうしたシステムは、本来は限られた人しかアクセスできないようにパスワードなどを設定するべきところが、施設の名前や水位、水門の状態などがインターネット上で丸見えになっていました。 このため、もしサイバー攻撃を受けてシステムが停止すれば、水位などの把握ができなくなるおそれがあったほか、中には、水門を勝手に操作されるおそれがあるものもありました。 内閣サイバーセキュリティセンターではインターネット上のアドレスを一つ一つチェックし、問題が見つかるごとに自治体などに連絡してパスワード
Azure 障害との上手な付き合い方
2017/4/22 Japan Azure User Group (JAZUG) Global Azure Bootcamp 2017 @ Tokyo https://jazug.connpass.com/event/52917/Read less
情報システムの障害状況ウォッチ（2016年後半） - 勘と経験と読経
SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。 過去に書いた関連記事は以下の通り。 情報システムの障害状況ウォッチ（2016年前半） - 勘と経験と読経 情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム - 勘と経験と読経 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経 SEC Journal最新号の入手はこちらから。 最新号とバックナンバー：IPA 独立行政法人 情報処理推進機構 情報システムの障害状況ウォッチ（2016年後半） 詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案
JINS はマジでやばい
https://twitter.com/piyokango/status/844361226767380481 という話があり、その現物なのだが、 http://www.freezepage.com/1490165400GAZZVSXBDT である。キャッシュの freezepage ですまんが、まあいいだろ。 これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題は JINS の対応だ。 t_jins_gmo_brandtoken_cancel_if_rireki t_jins_gmo_brandtoken_change_if_rireki t_jins_gmo_brandtoken_entry_if_rireki t_jins_gmo_brandtoken_exec_if_rireki などといった
我々はいかにして技術選択を間違えたのか？ 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！アプリケーション基盤チームの横田(@yokotaso)です！ kintoneなどで利用していたJavaフレームワークのSeasarのEOLに伴い、S2Daoからの脱却を試みたのですが、パフォーマンス問題や障害を発生させてしまうなど問題を多々発生させてしまいました。 同じ過ちを繰り返さないという強い決意のもと、今回の失敗をブログで公開いたします。 失敗をあえて公開する点で斬新かつ濃いブログ記事となっております！ 失敗体験の公開は恥だが役に立つ！ 移行先の選定の失敗 移行先として選定したプロダクトは Hibernate*1です。 Hibernateを選んだ理由としては Spring Framework を選定した Spring Frameworkで Interface + アノテーションでプログラミングするならSpring Data JPA が有力 JPAに準拠したのORMの中でも、H
富山大学 水素同位体科学研究センターへの不正アクセスについてまとめてみた - piyolog
2016年10月10日、富山大学 研究推進機構 水素同位体科学研究センターで標的型攻撃による情報漏えいが発生したと読売新聞が報じました。富山大学は同日にこの報道を認める発表を行っています。ここでは関連情報をまとめます。 富山大学の公式発表 2016年10月10日 「富山大学水素同位体科学研究センター」における標的型サイバー攻撃に関する報道について (魚拓) 2016年10月11日 富山大学水素同位体科学研究センターに対する標的型サイバー攻撃について (魚拓) [PDF] (別紙) 富山大学水素同位体科学研究センターに対する標的型サイバー攻撃について（概要） インシデントタイムライン インシデント発覚前 日付 出来事 2015年11月5日 富山大学に不審なメールが届く。(1回目) 2015年11月17日 富山大学に不審なメールが届く。(2回目) 2015年11月24日 教授と非常勤職員に標的
ウィルス感染でWebサービスが20日間ダウン。本当にごめんなさい - Qiita
障害が起きたWebサービスは個人で運営しているサービスです。 2016年2月、障害から20日後にサービス再開しましたがアクティブユーザは以前の18%です。未だ回復の目処は立っていません。冗長化していないサーバがウイルス感染し、その後の対応も後手後手に回ってしまいました。 2016年1月末に起こるべくして起こった障害について記事にしてみました。ご迷惑をお掛けしてしまい本当に申し訳ありません。 ■ ユーザは、もう戻ってこない どんなウイルスに感染したのか SYNフラッド攻撃（SYN Flood Attack）を他のWebサイトに行うウイルスに感染して、確認していませんが他のサービスをSYNフラッド攻撃していたと思います。またウイルス感染時にサーバのsshdを書き換えられsshで接続できなくなりました。感染後にコンソールログインして書き換えられた醜い authorized_keys を見た時ゾッ
終了した容量無制限オンラインストレージサービスまとめ – プログラミング生放送
人は何度 容量無制限にだまされ続けるのか。容量無制限だったけど、終了してしまったオンラインストレージ系のサービスをまとめてみました。ツイートやはてブのコメント等で追加情報もお待ちしています。 Fueruアルバム 2019/2/18 スマホの写真データを無料・ストレージ容量無制限で自動保存するクラウドストレージサービスを開始。 2021/9/21 有料プランを追加し、5,000枚まで無料に変更。 関連リンク ナカバヤシ、写真ストレージアプリ「Fueru アルバム」を公開 - デジカメ Watch 画像専用ストレージアプリ 「Fueru アルバム」の無料配信を開始 | ニュース詳細 | ナカバヤシ株式会社：アルバム・製本・シュレッダー・情報整理の総合サポーター ニュース詳細 ｜ 高品質なフォトブック、フォトアルバム作成なら、フエルフォトブック！ しまうまアルバム 2015/7/1 しまうまプリ
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
