Site Reliability Engineering における 重要領域とパフォーマンス指標の提案 / Performance Indicators for SRE2021/06/04 第8回WebSystemArchitecture研究会（オンライン） https://wsa.connpass.com/event/207143/
『Effective DevOps』読んだ: DevOpsという文化の作り方
✕✕即時性: コミュニケーションがどれだけ早く成立するかオーディエンスへの浸透度 : オーディエンスにメッセージを届けるためにどれくらい効果的か負担: そのコミュニケーションに参加するための必要な時間と労力コンテキスト: 特定のコミュニケーション方法で必要とされるコンテキストがどれくらいあるか構成の緻密さ: 伝えたいことがどれくらい緻密に構成されていなければいけないか優れたリーダーの条件周囲から最良のものを引き出す 自分自身や少数の「ロックスター」だけを重視してはならない。周りにいるすべてのひとたちから裁量のものを引き出せ優秀な組織とそうでない組織の違いはこの能力の有無で出るメンバー個人のビジョンと企業やチームのビジョンを一致させるように支援する規範たれ リーダーは自分が期待している行動の規範となるべきまわりのひとはリーダーの悪い行動も真似ることがあるので気をつけろクソの傘たれ 上層部から
IaC Maturity Model と学習ステップ #srefm - ツナワタリマイライフ
はじめに 先日、ノリと勢いで企画した SRE.fm を行い、ゆるふわに Terraform や IaC の話をしました。 sre-fm.connpass.com 実際にやってみて、質問への回答を行う中で、IaC に関わるひとたちのマジョリティと自分たちには大きな隔たりがあるような感覚を持ちました。そういった中で、質問の1点1点に答えるというよりも、大局的な理解であったり、その本質的な要素であったり、段階に分けた学習ステップ等を言語化することが必要なのではないか、と（その後の二次会で）たどり着きました。 「IaC は当たり前になった」というのは Infra Study Meetup #1「Infrastructure as Code」 での Mizzy さんの言葉で、これに関しては大きく同意するものの、この「当たり前」は「誰でもしている状態になった」「できていないのはありえない」というもので
1人目の専任SREがポストモーテム文化を改善したらエンジニア以外にも広まり、他部門との連携も強化された話｜Hiroki Takatsuka
2022年7月に primeNumber に入社した、1人目の専任 SRE の高塚 (@tk3fftk) です🙏 primeNumber が開発する trocco® のSREチームは現在、CTOの鈴木さん (@kekekenta) と自分、業務委託の方数名で日々さまざまな改善を行っています。 入社して半年以上経ち、行ってきた改善をふりかえりを行いがてら、記事を書いてみることにしました。 この記事では、SREの取り組みの1つとして、primeNumber のポストモーテム文化を改善した話をします。 追記: この記事をベースにしたLT登壇の機会をいただきました🎉 ポストモーテムとは?ポストモーテムとは、簡単に言うと、発生したインシデントについて読めば把握できるようなドキュメントです。 影響範囲、根本原因、タイムライン、行われた対応や再発防止策などが含まれます。 具体的な定義や書き方について
「学習する組織」を読んでいる - YusukeIwakiのブログ
まじでこれはいい本だ 読み始めたきっかけは、クラウドワークスエンジニアブログにあったtmknomさんの 「無人化システム」を駆逐する組織マネジメントとエンジニアリング の記事だ。組織論の話なのかな？と思わせるタイトルだが、「システム思考」などの理論を説明している部分が主だ。 （まだ全部読み切ってない段階でこんな記事書くなよ！って感じだけど、とりあえず書くｗ） 自分は、↑「なぜあの人の解決策はいつもうまくいくのか？」を読んでから、学習する組織を読み始めている。いきなり学習する組織を読むと、かなり面喰らうんじゃないだろうか。どちらの本も似たようなことを書いてるんだけど、「なぜあの人の・・・」のほうが具体例が身近でわかりやすい。 読んでいて感じたこと 国語力が皆無な自分ながらも、感じたことをいくつか書いておく。 スナップショットで判断するのではなく、時間をかけてシステム理解をする 暫定対処を重ね
産業安全についての神話（Some myths about industrial safety）について調べた - 勘と経験と読経
The DevOps ハンドブック 理論・原則・実践のすべてで紹介されていた「産業安全についての神話」（補章E）が面白そうだったので調べてみた。ソフトウェア開発に限らず、工学全般の話。 The DevOps ハンドブック 理論・原則・実践のすべて 作者: ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス出版社/メーカー: 日経BP社発売日: 2017/07/04メディア: Kindle版この商品を含むブログを見る 複雑なシステムに対する数十年の研究の結果、危険への対応策はいくつかの神話に基づいていたことがわかった。 原文はおそらくこれ Some myths about industrial safety(PDF) なお以下私の誤読の可能性もあるので、興味があれば上記の原典論文を参照のこと。 神話1：事故やインシデントの唯一最大の原因はヒューマンエラーである 原因をヒューマ
オライリー「Infrastructure as Code」で印象に残ったポイント - てくなべ (tekunabe)
先日、オライリー「Infrastructure as Code」の日本語版が発売されました。 www.oreilly.co.jp 副題にある通り「原則とプラクティス」をメインに書かれていて、特定のツールに依存しない内容になっています。 特に1章「課題と原則」は何度も読み直したくなる内容でした。（さらに言うと"1.2.1 Infrastructure as Code の目標" は壁に貼っておきたいような内容） 全体としては 「 予防より復旧 」が重要という印象をうけました。 一通り読んでみましたので、個人的に印象に残ったポイントをまとめます。 1. 大きな変更より小さな変更を日常的にする 小さな変更のほうが失敗したときに問題を特定しやすく、戻しやすい。 小さな変更のほうが確実に改善でき、モチベーションも保たれる。 2. システムを絶えず変更し、改良しているチームの方が大小の障害に対処できる力
SREの探究 - Spotifyの事例：Ops-in-Squads | フューチャー技術ブログ
はじめにこんにちは、TIG 岸下です。 秋のブログ週間の5本目になります。 最近、Netflixで配信中のSpotify創業ドキュメンタリー：The Playlistを見ました。創業ドキュメンタリーは鳥肌モノが多く、なんだかパワー貰える感じがして自分も頑張ろうと思わせてくれるので非常にオススメです1。 そんなわけでSpotify熱が高まっていたこと、自分がプロジェクトの方でSRE活動に関わっていることもあり、SREの探究：7章「SREのいないSRE：Spotifyのケーススタディ」を読んでみました。 そもそもSREって？恥ずかしながら、自分も現在のプロジェクトに配属されるまでSREの存在を知りませんでした。 SREはSite Reliability Engineeringの略で、サービスの信頼性をソフトウェアエンジニアリングの力で高めていこうぜ！というGoogle発祥の試みになります。 も
継続的デリバリーを2020年に読了した感想 - Kesinの知見置き場
継続的デリバリー 信頼できるソフトウエアリリースのためのビルド・テスト・デプロイメントの自動化 (アスキードワンゴ) 作者:Ｊｅｚ Ｈｕｍｂｌｅ,Ｄａｖｉｄ Ｆａｒｌｅｙ,和智 右桂,高木 正弘発売日: 2017/08/09メディア: Kindle版 業務で大規模なCI/CDパイプラインを構築することになったので、良書という話をよく耳にしていた継続的デリバリーを購入して読了しました。 普段は書籍を読んでもメモを残すことまではほとんどしないのですが、この本はかつて無いほど得るものが多かったので自分にしては珍しくメモを取りました。 自分と同じように大規模なパイプラインを設計することに迫られる人は世にそれほど多くないでしょうから、せっかくなので公開したいと思います。 全体まとめ この本の構成は1章で重要なことをほぼ全て述べて、あとの章でそれらをさらに詳しく解説している。同じことを後の章で何度も繰
継続的インテグレーション(CI)と継続的デリバリー(CD)について知りたかったら、闘うプログラマを読め - 未来のいつか/hyoshiokの日記
継続的インテグレーション(CI - Continuous Integration)と継続的デリバリー(CD - Continuous Delivery)について知りたかったら、闘うプログラマー［新装版］を読もう。 これはWindows NTの開発物語だ。大規模基盤ソフトウェアの現場の葛藤を生々しく描いていて、ソフトウェア開発に従事しているものには必読書といっても過言ではない。 デスマーチ、ドッグフードを食う、ビルド、業界人なら誰でも聞いたことがあるジャーゴン（業界用語）がちりばめられている。本書によって、それらの用語を覚えた人も少なくないと思う。 「カトラー（開発の総責任者、伝説のプログラマー）は、オペレーティング・システムを開発するときは、機能を増やすより、スケジュールを短縮するべきだと考えている。最初のバージョンは、機能を減らしても、早くリリースしたほうがいい。最初は機能を最小限にして
SRE book から学んだことと、献身と愛情、2018 年の行動指針について
Tweet 📕 SRE book を読んだ SRE という肩書で仕事をしはじめてそろそろ 2 年たとうかというところで、いつか読もう読もうと思って読んでいなかった Site Reliability Engineering、いわゆる SRE book の日本語訳版を年末年始にかけて読みました。 SRE という肩書で業務に取り組んでいる人はもちろん、そうでないインフラエンジニアやサービス開発に取り組んでいるエンジニアの皆さんにも、ぜひオススメしたい一冊です。わたしは最初から最後まで通読しましたが、章ごとに扱っているテーマは分かれているため、興味のある章を拾い読みするのもよいでしょう。一部他の章の知識が必要なところもありますが、そのような章へのリファレンスがキチンとついているので良心的なつくりになっています。 💡 どのような事柄が学べるか この本がカバーしている内容は非常に広範です。まず「G
朝活として最高の書籍である『システム運用アンチパターン』を読んだので読書感想文 - じゃあ、おうちで学べる
はじめに SREという信頼性の観点からのプラクティスや運用技術を実施出来るためのプロダクトの開発をしている身からすると『システム運用アンチパターン』はまさに様々な課題がわかりやすく言語化されており素晴らしい書籍で、熟練の運用エンジニアとお話ができるような経験ができました。このエントリーは『システム運用アンチパターン』を読んでみた中での感想文となります。 www.oreilly.co.jp 『システム運用アンチパターン』目次 1章 DevOpsを構成するもの 1.1 DevOpsとは？ 1.2 DevOpsの柱となるCAMS 1.3 また別のDevOps本？ 1.4 本章のまとめ 2章 パターナリスト症候群 2.1 安全装置ではなく障壁を作ってしまう 2.2 ゲートキーパーの導入 2.3 ゲートキーパーの分析 2.4 自動化によるパターナリスト症候群の解消 2.5 承認の目的を把握する 2.
「エンジニアのためのリスクマネジメント入門」を読んだ - けんちゃんくんさんのWeb日記
タイトルには「エンジニアのための」とあるが、3章の事例がエンジニアにとって身近な話題というだけで、一般的なリスクマネジメントの歴史から言葉の定義、関連する標準規格まで幅広くおさえられる書籍だと感じた。 特に、リスクコントロールの4つのパターン、「保有」「低減」「回避」「移転」という考え方を知ることができたのは、明日から役立つ内容でよかった。 仕事でもリスクの評価と対応について検討する機会があるが、リスクの評価については書籍のとおり「発生可能性」と「影響度」でマッピングしているものの、その後の対応をどうするかというのは迷うことがあった。この本のおかげで、より自信をもって論理的に判断できるようになったと思う。「リスクを保有する」と判断することもコントロールしていることなのだ。 また、3章のコラム的なところで、「防止的コントロール」と「発見的コントロール」という概念を知ることができたのも収穫だっ
複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail) - 勘と経験と読経
How Complex Systems Fail – Perspectives の記事で紹介されていた「複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail)」という論考が興味深かったので紹介する記事。 How Complex Systems Fail(PDF) 詳細はリンク先のPDF参照だが、紹介されている18条だけ簡単に紹介しておく(DeepL翻訳)。 複雑なシステムは本質的に危険なシステムである 複雑なシステムは故障に対して重く、うまく防御されています 大災害は複数の失敗を必要とする - 一点の失敗では十分ではない 複雑なシステムには、その中に潜んでいる欠陥の変化する混合物が含まれています 複雑なシステムは劣化モードで動作する 破局は常に角を曲がったところにある 事故後の事故を「根本原因」に帰属させることは根本的に間違っている 事故後の人間のパ
開発チームのパフォーマンスを測る指標を学ぶ - 「LeanとDevOpsの科学」読んだ - $shibayu36->blog;
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog; に続いて、現代のソフトウェア開発について学ぶために、LeanとDevOpsの科学を読んだ。 LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ 作者:Nicole Forsgren Ph.D.,Jez Humble,Gene Kim,武舎広幸,武舎るみインプレスAmazon この本は開発チームのデリバリのパフォーマンスを測るための統計的に有意な指標を示してくれていることが、とにかく素晴らしい。これまで開発チームの生産性や健全性をどういう指標で測れば良いか分からなかったが、本でデプロイの頻度、変更のリードタイム、MTTR、変更失敗率を測れば良いと示してくれた。今後は自分のチームでこの指標を測り
「入門 監視」を読んで見えてきた現状の課題と改善点 - エムスリーテックブログ
こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。 「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました！ www.oreilly.co.jp 監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。 本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。 モニターリザード 各章の感想 「1章 監視のアンチパターン」について 「第2章 監視のデザインパターン」について 「3章 アラート、オンコール、インシデント管理」について 「5章 ビジネスを監視する」について 「6章 フロントエンド監視」について 「7章 アプリケーション監視」について
オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい
最近は、@kazeburo さんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは 1 年前くらいで、その時僕は 2 年目に入ったところで MySQL Conference から帰ったばかりで「おらは DataBase Administrator(DBA)なんだ！」と思ってた頃でした。 それからちょうど 1 年。1 年目の時も DB だけをやってたわけではないですが、この 1 年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど ん、ちょっと待てって？
入門 入門 監視 / reading-practical-monitoring
「入門 監視」を読んだので、自分たちのチームに当てはめて考えてみる
SRE 本は二度以上読む価値がある - 誰かの役に立てばいいブログ
@tamagawa_ryuji 氏からこの度和訳して発売された「SRE サイトリライアビリティエンジニアリング」をご恵贈いただきました。 英語の原本は昨年発売されており、Google のサービス運用について実践的な知見が得られる貴重な書籍ということで、去年のうちに英語版を社内で購入し、輪講しています。今回和訳本を頂きましたので、二度目となりますが早速拝読しました。 SRE (Site Reliability Engineering) という言葉を聞きなれない方のために簡単に解説しておくと、Google において古典的なシステム管理者の概念に代えて導入された、システムとその上のサービスの信頼性に責任を持つエンジニアとその仕事のやり方の体系的な概念です。 初めて読んだ際は、SRE とそれにまつわる Toil や Postmortem といった概念や SLO の定義の仕方について Google
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「監視の目的とは何か？」問いかけよう / Practical Monitoring
