ゼロから始めるシステム障害対応フロー - Qiita
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
OSSで新機能要望やバグ報告を全てGitHub Discussionsに起票してもらうことにしてみた - knqyf263's blog
今回の案は自分のメンテナンスしているOSSだと回りそうという話で、これが他のプロジェクトにとっても良いと勧めているわけではないです。 ふーんそういう運用をしているところもあるんだと思って読んでもらえればと思います。 要約 背景 質問への回答 バグ報告のノイズ バグと言われることの精神的苦痛 新機能要望 Issuesの横の数字が増えていくことへの嫌悪感 Issues対応への強迫観念 マイルストーン決めるときにタスクの選定が面倒 運用案 利点 タスクの分離 コミュニティ内のコミュニケーション促進 メンテナの精神的負担軽減 懸念 アサインができない 参照しているIssuesが表示できない トリアージが終わっていないバグはissueにならない 再現ができないバグはissueにならない ユーザがバグ起票後にすぐPRを作ることができない 実現方法が思いつかないだけで追加したい新機能がissueにならな
オープンソースでセルフホスト可能＆自由自在にプランをカスタマイズ可能な課金管理システム「Lotus」使用レビュー
「使った分だけ課金」という仕組みはシンプルで分かりやすいですが、一方で使用量をユーザーごとに計測して請求金額を算出する仕組みはなかなか複雑になってしまいがちです。「Lotus」はそうした複雑な課金管理を一発で解決できるツールとのことで、どんなことができるのか実際に確かめてみました。 Lotus — Open Source Pricing and Billing Infrastructure https://www.uselotus.io/ LotusのサーバーはDockerを利用して起動するため、下記のリンクから自分の環境に合った方法でDockerをインストールします。 Install Docker Engine | Docker Documentation https://docs.docker.com/engine/install/ 今回はCentOSを利用するため、下記のコマンドを入
ルールの運用から始めるフロントエンド開発改善
フロントエンドの開発で開発者体験が下がったときには、適切なルールの運用を始めるとよいのではないか、という話をしています。 特に主張したいのは12ページ目です。
私がインフラ運用保守で意識して行っていること(コラム) - Qiita
～はじめに～ 運用保守は、手順書通りするだけの楽な業務と勘違いしていませんか？ 私は3年間運用保守(インフラ)に携わり、手順書作成や障害対応/調査、運用支援など様々なことを行ってきました。そんな私が思うに運用保守は、全くそんな楽な業務でありません。 運用保守は過信と油断をすれば、すぐに業務影響を出してしまいます。 構築設計段階でのお客様に影響を出すのとは、全く影響度合いが違います。 既に稼働しているシステムで業務影響を出すというのは、エンドユーザーへ多大なるご迷惑をおかけするということ、つまり絶対に許されません。 そんな状況にならないために、私が運用保守をする上で意識して行っていることについて書きたいと思います。 ～運用保守をする上で意識して行っていること～ 1. 簡単な作業や慣れた作業でも慎重に行う 私はどんな作業だとしても、過信や油断をせずに慎重を行うようにしています。 簡単または慣れ
【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 - Qiita
はじめに 先日私が書いたこちらの記事がQiitaのトレンド１位になりました。ありがとうございます！ 今回はこちらの構成を作成するにあたって参考になった書籍を紹介していこうと思います。どれも大変素晴らしいので、是非読んでみてください。 ただ、何よりも参考になったのは 公式ドキュメントとそのサービスを実際に触ってみる事です。英語のドキュメントしか無いものも多く大変だとは思いますが、気になったサービスは是非一度公式ドキュメントを見ながら触ってみてはいかがでしょうか。 ※先日の記事で紹介した"ぼくのかんがえたさいきょうの"運用・監視構成をもう一度載せておきます。 監視 全般 入門 監視 言わずもがなオライリーの本です。こちらは監視のアンチパターンとデザインパターンと、何をどのように監視すればいいかを学べます。 監視を入門する際はまずこちらの本から読むのがおすすめです。監視についての基本的な考え方が
Composite Action実践ガイド：GitHub Actionsのメンテナンス性を高める技法
『Composite Action実践ガイド』はGitHub Actionsに関心のあるソフトウェアエンジニア向けのZenn Bookです。 本Bookでは「Composite Action」の実運用で役立つプラクティスを紹介します。テスト・静的解析・セキュリティ・ドキュメンテーション・依存関係管理・リリースマネジメント・Reusable Workflowsによる開発体験の向上など盛りだくさんです。 Composite Actionはシンプルなので、ただ実装するだけなら難しくありません。しかしメンテナンス性を高め、一貫性を維持するのは難しい仕事です。さらに利用者に優しく使いやすいものを提供するには、高いホスピタリティも求められます。 そこで本BookではComposite Actionの利便性を高め、持続的に進化させるためのアイデアをたくさん散りばめました。Composite Action
発表資料 — OpsLab
業務/システム運用に関する執筆記事/論文/発表 (2013〜)¶ 【インタビュー記事】 運用でカバーの波田野さんが現場で得た経験則とCLI支部への思い (JAWS-UG on ASCII.jp / 2016年7月) 【インタビュー記事】セキュラボ 『もう一人の視点対談 乗口雅充 X 波田野裕一 (前編) (2016年5月) 『もう一人の視点対談 乗口雅充 X 波田野裕一 (後編) (2016年7月) 【連載】Sphinxで始めるドキュメント作成術 (Software Design / 共著) 第16回 Sphinxで運用ドキュメントを作る 【講演】 クラウドネイティブ時代のインフラエンジニア (Internet Week 2015 / 2015年11月) 【レポート】 Monthly News from jus 42: セキュリティとクラウドの新潮流に触れたInternet Week (S
【運用監視ツール比較】ZABBIXからPrometheusへの移行を開始しました - WILLGATE TECH BLOG
概要 運用監視ツールの比較検討をして、ZABBIXからPrometheusへ移行することにしました。 その経緯を書きます。 現状 弊社ではAWSやさくらのクラウド、ConoHaのクラウドなど様々なIaaS/VPSを使って暮らしニスタやMillyなどのサービスを展開しています。 監視対象VM数は170台程度です。 抱えていた課題 重い 監視対象が増えるにつれて重くなってきて、素早く情報を見たい時にストレスになっていました。 ZABBIXのDBはMySQLを使っていましたがパラメータチューニングが必要で、運用に手間がかかっていました。 サポート切れ ZABBIXサーバのバージョンが2.2で、サポート期限の終了が2019年8月と近づいてきていました。 （詳細は公式情報をご覧になってください） スクリーン作成の難しさ ZABBIXはグラフをまとめたものをスクリーンと呼んでいるのですが、スクリーン作
2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
｢手順書｣のススメ - Masteries
こんにちは, id:papix です. この記事は, ｢はてなエンジニア Advent Calendar 2018｣の9日目の記事です. qiita.com 昨日は id:wtatsuru さんによる, ｢基盤開発観点からみたはてなのAWS活用のこれまでとこれから｣でした. wtatsuru.hatenadiary.com ｢手順書｣のススメ さて, 早速本題に入っていきましょう. 皆さんは｢手順書｣を書いていますか? 自分はと言うと, 最近そこそこの規模のオペレーションが必要なタスクを担当する機会が多く, その度に手順書を書いて, レビューしてもらってからオペレーションをするようにしています. 例えば, 今年実施した｢はてなが提供するドメインを利用したブログのHTTPS化対応｣のリリースの時は, このような手順書を書いていました: この時は, GitHubのIssueに手順書を用意してい
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD - Part 89
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、大きな問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、エラ
一見、理解されがたい仕事のスキルの所有者たちが、正当に評価され、報われますように
いきなりですが皆さん、システムの保守・運用っていうと、どんなことする仕事なのかってご存知ですか？ 勿論、一言で保守とか運用って言っても、対象となるシステムにもよりますし、担当者の守備範囲にも、契約の内容にもよるんで、あまり一概に言える話でもないんです。 ないんですが、それを承知でざくっと言ってしまうと、例えば一般的なwebシステムでいえば、 ・システムの負荷監視、死活監視、パフォーマンス監視 ・トラブル時の調査・問題切り分け・障害対応 ・インフラの故障対応 ・ネットワーク監視 ・バックアップ対応 ・定期メンテナンス ・ジョブ管理 ・マニュアル・ドキュメント管理 ・障害対応訓練 ・バージョン管理・変更管理 ・ログ管理 ・セキュリティパッチ対応 ・瑕疵対応、バグ対応 ・修正開発時の事前調査 この辺については、まあ代表的な保守・運用の仕事と言ってもそんなに問題ないでしょう。正確にいうと、保守と運
社内障害情報共有のススメ - Hatena Developer Blog
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。 障害情報を社内共有する理由 サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。 障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。 そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために
開発者が運用を経験すべき一つの理由 | DevelopersIO
はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計／実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜ日本の運用業務はつらいのか /20190910-most-important-for-operation
宣言型デプロイツールの「正しい」使い方 (考え方編) /20180524-ssmjp-deploy
運用現場におけるSRE本の「正しい」読み方
運用自動化、不都合な真実 // Speaker Deck
