障害対応をがんばるPMは尊い｜さとじゅん
メルペイでPMしてます、さとじゅんです。 言いたいことはタイトルの通りです。 「障害対応がんばるPMは尊い！！！！！！！！」」 現場からは以上です。 ありがとうございました。 、、、と言うくらい、タイトルでもう言いたいことの80%くらいを言い切ってしまいました。 ちなみに最初に言っておきますが、障害対応自体はPMだけでなく関わった方すべてが尊いです。 これは間違いありません。 今回はPMに焦点をあてた内容にしたかったのでこのタイトルにしました。 障害が起きた時、とてもプレッシャーのかかる局面だったかと思います。 なにが起きてるのかわからず焦ってしまったと思います。 それでも仲間と乗り越えてきたんだと思います。 みなさま本当にいつもお疲れさまでございます。 まえおきということで、プロダクトを運用していく過程で障害対応は避けては通れないですよね。 昨今の華々しいプロダクトマネジメント論はプロダ
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
「背筋の凍るシステムダウン」についてIT企業の最高技術責任者たちが赤裸々に経験を語る
ウェブサイトやアプリケーションは「常に稼働していること」が望ましく、大規模なサービスになればなるほど停止した際の損害は大きくなります。しかし、人的ミスやハードウェアの故障、予期せぬバグによるシステムダウンはいかなる時でも起こりうるもの。そんな恐ろしいシステムダウンの経験談を6人の最高技術責任者(CTO)が赤裸々に語っています。 6 Scary Outage Stories from CTOs – The New Stack https://thenewstack.io/6-scary-outage-stories-from-ctos/ ◆Honeycomb CTO：Charity Majors氏 Majors氏が語る障害は「プッシュ通知のシステムダウン」です。システムの状態は正常でMajors氏自身も通知を受信できており、テスト通知も成功していたため、最初は何が起きているのかわからなかった
Netflixを支える推薦システムの裏側｜masa_kazama
イントロNetflixは、スマホやPCがあれば、どこでもいつでも、映画やドラマを見放題で楽しむことができます。今年はお家時間が増えたことで、Netflixをより満喫している方も多いのではないでしょうか。実際に、2020年1月〜3月に会員が全世界で1600万人ほど増え、合計1億8000万人を超えています。 Netflixをいくつかの数字で見てみると、さらにその凄さに驚かされます。 ・全世界のインターネット通信量(下り)の15%をNetflixが占めており、YouTubeを超える世界一の動画サービス ・時価総額が20兆円超え ・サブスクリプション収入が月々約1500億円 そんな多くのユーザーを有するNetflixの魅力の１つに、推薦システムがあります。Netflixのホーム画面には、今話題の作品やユーザーにパーソナライズ化されたおすすめの作品が並びます。 Googleの検索と違って、Netfl
DXって何じゃらほい？或いは2025年の崖っ淵に向かって熊とワルツを踊る刹那について｜楠 正憲（デジタル庁統括官）
何週間か前のこと、急にエンプラっぽくないAIベンチャーの社長さんからメッセで飲みに誘われ、秋葉原の焼き鳥屋さんでDXとやらについて聞かれて、とりあえずこのレポート読んどけと返しつつも考えちゃった訳です。Direct Xとか、よくテレビに出てるマツコの方じゃなくて「2025年の崖って実際どうなんだ？」とか何とかオッサンたちから相談される話あるじゃないですか。あれって何なんですかね？オンプレをクラウドにリフトしたらDXなのか。華麗にk8sやらコンテナ使いこなしてCIパイプライン組み立ててテスト自動化したらDXなのか、だいたいDigital Transformationなのに、どうしてDXなのか。SAP R/3とCOBOL PL/Iを捨てて、どこぞのSaaS入れてSparkぶん回してPythonとか書いたらDXなのか。おいおい、そんな話だっけ？って心配になっちゃう訳です。 内製内製って簡単に言う
なぜ「システムが無事に動いている」ことの価値は理解されないのか
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
Pinterestはいかにスケーラビリティと格闘してきたのか（後編）。QCon Tokyo 2013
4月23日に都内で開催されたエンジニア向けのイベント「QCon Tokyo 2013」。急速に人気サイトへと成長したPinterestが、その裏でいかにスケーラビリティと格闘してきたのかをPinterestのエンジニア自身が紹介するセッション「Scaling Pinterest」が行われました。 この記事は「Pinterestはいかにスケーラビリティと格闘してきたのか（前編）。QCon Tokyo 2013」の続きです。 クラスタリングは怖い スケーラブルなシステムで問題なのは、データベースがひとつのサーバに収まらなくなったときにどうするのか、ということだ。 例えば、Cassandraは自動的にスケーリングしてくれて設定も簡単。可用性も高く単一障害点はない。しかし障害はそれでも起こるもので、クラスタリングの技術はまだ枯れておらず基本的に複雑なものだ。コミュニティもまだ十分ではない。 私たち
Pinterestはいかにスケーラビリティと格闘してきたのか（前編）。QCon Tokyo 2013
4月23日に都内で開催されたエンジニア向けのイベント「QCon Tokyo 2013」。急速に人気サイトへと成長したPinterestが、その裏でいかにスケーラビリティと格闘してきたのかをPinterestのエンジニア自身が紹介するセッション「Scaling Pinterest」が行われました。 この記事では、その内容をダイジェストで紹介しましょう。 つねにシステムのどこかが壊れている Pinterest、Marty Weiner氏。 Pinterestはオンラインのピンボードで、ユーザーが「ボード」を作成して、そこに画像など好きなものをアップロードしてシェアできるというもの。「ピン」ひとつひとつが画像やリンクになっている。 ユーザーやボードをフォローすることもできるし、再ピンしたりイイネしたり、コメントの入力もできる。
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
第3回 抜本的解決へのサービス停止も後手に
夜間バッチの遅れが解消されず、さらにATMの全面ダウンも引き起こしたことから、みずほ銀は3月18日、抜本的な障害対応に乗り出すことを決めた。 障害対応にシステムのリソースを集中するため、18日から22日にかけて、店舗外ATMやインターネットバンキングなどの停止を決めた（図）。さらに3連休の間はすべてのATMを止めることにした。 18日午後1時30分、みずほ銀本店ビル22階に、障害対策チームのオペレーションルームを設けた。そこに、みずほ銀のIT・システム統括部とシステム運用部、みずほ情報総研、システム運用を担うみずほオペレーションサービスの担当者が集まった。障害発生から5日後にようやく、3社の障害対策チームが一本化した（表-28）。 これに前後して、手動で行っていた夜間バッチを効率化するため、TARGETを改良し、処理を自動化できるようにもした。 18日からの巻き返しによって、19日午後7時
第2回 読み誤りや誤削除など人為ミス続発
みずほ銀のSTEPSは1988年に稼働を開始した。当時は、ATMの24時間稼働も、インターネットバンキングも、携帯電話を用いた振り込みサービスも存在しなかった。 その後、これらのサービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった（表-18）。 さらに、携帯電話での振り込みといった新サービスを導入する際に、夜間バッチの負荷テストを行っていなかった（表-19）。 みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかった（表-20）ため、こうした問題に気付くこともなかった。 みずほ銀はシステム監査において、「システム運用管理体制」のリスクを最高レベルとしていない（表-21）など、リスクの大きさを正しく把握することができていなかった。 夜間バッチが異常終了した原因は、口座bの振り込みデータを振り分ける（分割する）処理で、上限値
第1回 重なった30の不手際
東日本大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日本大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座（以下、口座a）に、振り込みが殺到した。 午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。 みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた（表-1）。 みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口（ぐち）」かである。 これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座
みずほ銀行の3月のシステム障害の調査報告pdfが超面白いのでマはみんな読むべき « おれせん。
みずほ銀行：システム障害に関するお知らせおよびお問い合わせ先 http://www.mizuhobank.co.jp/oshirase.html 中段の「システム障害特別調査委員会の調査報告書について」のリンク 直リンクはこれ（5/20掲載） 前半しばらく「グダグダ鬱陶しい能書き」が続きますが9ページ目の「3. 本障害発生以前のシステム障害及び対応状況」あたりからギアが入って、11ページ目の「4. 本障害の発生事実」からトップギアというかちょっとしたヘル絵図であります。 ……ああ、その前にここを引用しておこうかな、4-5ページの「2. システムの概況」内「(3) 次期システムの概要」箇所。 (3) 次期システムの概要 次期システムについて、ビジネス環境の急激な変化に対応すべく、肥大化・複雑化した現行システムを新たなシステムとして再構築するために、2004 年から MHFG を中心に検討
エラー率わずか0.00000625％、驚異のインド式昼食配達システム「ダッバーワーラー」
日本の物流システムのものすごさはよく知られたところ。徹底的なコンピューター化による管理と、そして日本の道路・通信インフラの優秀さによって高速かつ精密な輸送を可能にしているわけですが、これにまさるとも劣らないシステムがインドにもありました。社会的なインフラがまだまだ未整備なのにも関わらず、伝票もPOS端末も携帯電話も一切なんにも使わずに毎日20万食の昼食を時間通りに届ける「ダッバワーラー」という驚異のシステムが存在しているのです。一体どんな人達なのでしょうか。 目次 ダッバーワーラーとは ミスは1600万回に1回、驚異の低エラー率 超複雑なネットワークを人力で運営するダッバーワーラー達 なぜダッバーワーラーは超低料金で超優良サービスを提供できるのか？ ダッバーワーラーと組織の社会貢献 ダッバーワーラーとは インドの人達には、3食きちんと調理した温かい物を食べる、という食文化があります。これは
みずほシステム障害の全貌
みずほ銀行は今週、3月に発生した大規模システム障害に対する事後対応で、一つの区切りを迎えた。 5月20日、弁護士ら第三者で構成するシステム障害特別調査委員会の調査報告書が公開された。調査報告書には、障害の発生原因やその後に起こした複数の対応ミスにより障害が長期化した経緯の全貌が記されていた。 これを受け5月23日には、みずほフィナンシャルグループが再発防止策を発表。さらに、みずほ銀行の頭取とIT・システムグループ担当常務執行役員が責任を取り6月20日付で退任することを明らかにした。 経営トップの引責辞任によってみずほ銀行は「けじめ」を付けたが、システム障害の事後対応はこれで終わりではない。みずほフィナンシャルグループは再発防止策の一つとして、みずほ銀行、みずほコーポレート銀行、みずほ信託銀行の基幹システムを統合する考えだ。 2002年4月にみずほ銀行が誕生して以来、2度の大規模システム障害
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/coffee_nomimasu/status/1768648873042685986?s=43&t=soNcT6O2AeVewuhHm1Gciw
食品工場の見学に行ったら食品衛生に関する部分がシステム化されててすごかった「やらないと扉が開かないマシーンまみれ」
大貫剛🇺🇦🇯🇵З Україною on Twitter: "みずほATMのトラブルを見てると、JR東日本のSuicaシステムは先見の明があったなと思う。全システムがダウンすると首都圏の通勤が麻痺してしまうおそれがあるので、それを想定したシステムになってる。"
AKB総選挙を支えるパイプドビッツのクラウド基盤