初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が(ほぼ)ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO:プロダクトオーナー(Pd
1. はじめに こんにちは、SWEのあかりです。 今回のテーマは、SRE NEXT 2023のCall For Proposals(CFP) に応募したものの、残念ながら不採択になってしまったものです。話せるネタとしてはまとまっていたので、テックブログとしてここに捧げます😇 2. 本記事の概要 社内で最も古くから稼働している施工管理アプリでは、主にデータ修正と有事の際のログイン環境として開発者向けのEC2インスタンス(以降、「バッチサーバ」と表現)が存在していました。この記事では、このバッチサーバの廃止1を目的として、このサーバが担っていた役割をサーバレス環境・コンテナ環境へ移行し、EC2インスタンスからの脱却を達成した取り組み2について説明します。 この記事を読んで得られることは以下の通りです。 EC2インスタンスを廃止する取り組みの流れ 技術選定時に定性分析を行う事例 本番データを修
「文化芸術分野の適正な契約関係構築に向けた検討会議」での検討結果が、「文化芸術分野の適正な契約関係構築に向けたガイドライン(検討のまとめ)」としてまとまりましたので、お知らせします。 1.趣旨 文化庁では、文化芸術の担い手である芸術家等が安心・安全な環境で業務に従事できるよう、外部有識者による「文化芸術分野の適正な契約関係構築に向けた検討会議」を開催し、契約の書面化の推進や適正な契約関係の構築等について検討を進めてまいりました。 この度、同会議での検討結果が「文化芸術分野の適正な契約関係構築に向けたガイドライン(検討のまとめ)」としてまとまりましたので、お知らせします。 2.「文化芸術分野の適正な契約関係構築に向けたガイドライン(検討のまとめ)」について 別添1(概要)及び別添2(本文)のとおり 別添1「文化芸術分野の適正な契約関係構築に向けたガイドライン(検討のまとめ)」概要(452KB
文化庁のガイドラインをもとにした『アーティスト・スタッフのための契約ガイドブック』がWebで無料公開され、「素晴らしい」「勉強になる」などと話題になっています。音楽や舞台、美術や映像など、芸術分野で活動するフリーランスが安心して仕事をするために必要な、契約締結の要点を分かりやすく解説したものです。 アーティスト・スタッフのための契約ガイドブック 文化庁の「文化芸術分野の適正な契約関係構築に向けたガイドライン」を元に、契約における重要なポイントをまとめたガイドブック。依頼内容や報酬などについて取り決めが不十分なまま、口約束だけでプロジェクトが進みがちな文化芸術分野の現状に鑑みて、「なぜ契約が必要なのか」から説明されています。 受注側・発注側ともに安心してプロジェクトを進められるよう、適切な契約で取引の条件を明確に 前半は契約書の読み方や、各条項の重視すべきポイントを解説。例えば業務内容の条項
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木(@moomooya)です。 ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。 このプロジェクトで「WEBアプリケーションのDockerコンテナ移行」にまつわる検証を進めているので、その中間報告を共有しようかと思います。 本検証での想定環境 CIに不必要な部分は後回し 既存アプリでコンテナ化の障害になった部分 OSコマンドを利用している ミドルウェアとの密結合 オンライン系とバッチ系の密結合 ひとまず目指す状態 プロセス相乗りの影響 ログが複数出力される まとめ 続きの記事も書きました。 tech
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告(レポート)する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例: ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
こんにちは、id:shallow1729です。最近はインフラ寄りなお仕事をよくやっていますがこれまでにいくつかデータ移行やデータ基盤構築などのバッチ処理のお仕事をしてきました。以前にも一度そういった経験を元に記事を書いたのですが、MySQLやシステムに関する知識が以前よりも増えた今もう一度書き直したいなと思いました。 なので今回はバッチ処理を書く時のテクニック2022版という感じです。今の仕事の関係でMySQLやrailsを前提にしている話が多いですが、おそらく他のデータベースを使っている人にも役に立つ話が多いのではないかと思います。ただ、今回の記事は経験に基づくものが多く、あまりよくないアイデアもあるかもしれません。改善点や間違いなどあればご指摘ください。 冪等性を持つように 冪等性とは端的に言えばある操作を複数回実行しても一回しか実行しなかった時と同じ結果になる性質の事です。長時間かか
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては(
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約(と可能なら余談)だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"(>= 2.1.3みたいなやつ)の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
株式売買システム「arrowhead」の不具合が原因で10月1日に発生した東京証券取引所のシステム障害を巡って、機器を納入していた富士通は19日、製品マニュアルに不備があったとして謝罪した。今後は関係役員の処分を検討し、社長直轄の組織で再発防止に取り組むという。 障害の原因について富士通は「マニュアルの記載と実際の仕様の齟齬(そご)があった」と説明。マニュアルには「メモリ故障などが発生した場合は、必ず自動切替が行われる」との記載があったが、実際は自動で切り替わらない仕様となっていたという。 OEM先の米国企業が製品の仕様を変更した際、富士通がマニュアルの記載が変更されていないことに気付かず、仕様の変更も検知できなかったとしている。富士通は「当社の試験・確認が不十分だった」と陳謝した。 メモリ部品が故障した原因は、事前にOEMベンダーが故障部品の診断を行っているとして「ロット障害ではなく、偶
安全管理や労働災害防止は、難しくはありません。 過去の実例や経験を上手に活用すれば、かなりの程度、達成できます。 先人の犠牲は貴重な教訓です。 その一端を、順次ご紹介して参ります。 社会保険労務士・行政書士 横山事務所 所長 横山 誠 〒 262-0033 千葉県千葉市花見川区幕張本郷2-5-1-207 電話 043-272-3917 ファックス 043-272-3918 業務内容 主に、職場の安全管理、労働災害防止に取り組んでいます。 実際に発生した災害を4こまマンガで表し、その状況、原因、防止対策を検討して、安全診断、教育、講演等の材料にしています。 紙芝居風(パワーポイントも可能)の講演は、ユニークな手法として好評を頂いております。
Kubernetesやそれに関するソフトウェアについて交流や情報交換のための勉強会「Kubernetes Meetup Tokyo」。 前回は、ソフトウェアエンジニアとして働く村田俊哉氏(@shmurata_)がKubernetesのアップグレード前の作業について紹介しました。今回は、実際のアップグレードについて、それに付帯するアドオンやストレージバージョンの更新について経験者だからわかる視点で説明します。 kubectl drainについて 村田俊哉氏:メインのノードのアップグレードですね。ノードは、実際にサービスを稼働させているPodが動いているので、無停止でアップグレードするには、このPodをグレースフルシャットダウンさせてから、ノードを停止していく必要があります。ノードをグレースフルにシャットダウンする方法として、Kubernetesが提供しているコマンドkubectl drain
S U Z U@旅パッキングand客力の磨き方 @suzukyuin ヒューマンエラーの勉強をすると「気をつける」は対策ではありませんと、教え込まれるので。全てのものにフールプルーフ&フェールセーフをするようになるので、エラーが減ります。 エラーする人は自分を信じすぎでは?って思ってる。 S U Z U@旅パッキングand客力の磨き方 @suzukyuin 得にルーティーンで決まってることの途中でイレギュラートラップ(例えば話しかけられる、電話かかってくるとか途中の流れをインターセプトされる状況)が起きると、全部スッこ抜けて大事故につながるエラーを起こすので、そう出来ない仕組みを作るとかね。 とにかく「人は間違える」って思うの大事 S U Z U@旅パッキングand客力の磨き方 @suzukyuin とんでもないのは「自分は間違えない」って変な自信を持ってる人。この手の人は「間違えるわけな
セキュリティ対策室の伊藤洋也 @hiboma です。 業務中に、Haconiwa コンテナ で動くとある node プロセスが general protection fault ( 一般保護違反! ) を起こしてdmesg にログを残す現象を調べ、問題解決にあたっていました。その際の痕跡をまとめなおして記したエントリになります。 エントリの概要 本エントリでは、以下のような内容を扱います。 Haconiwa コンテナの node プロセスが general protection fault を起こしている ライブラリ関数 abort(3) の概要 abort(3) がプロセスを停止する方法の検証 node プロセスが abort(3) を呼び出すケース glibc x86系の abort(3) 実装が HLT 命令を呼び出し、general protection fault を起こすこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く