SREをはじめよう
TOPICS System/Network 発行年月日 2024年10月 PRINT LENGTH 320 ISBN 978-4-8144-0090-4 原書 Becoming SRE FORMAT Print PDF Webシステムの信頼性は、いまや企業と組織の信頼性にも大きな影響を及ぼしています。そのシステムの信頼性を確保するのがSRE、つまり「サイトリライアビリティエンジニア」と呼ばれる職種、あるいは「サイトリライアビリティエンジニアリング」という技能、活動です。 本書は、自身もSRE/DevOps/システム管理の分野で40年のキャリアを持つ筆者による、個人がSREになるための、また組織がSREを導入し、発展させるための指針を平易かつコンパクトにまとめた書籍です。 「SREとはどのようなものか」「SREになるには何をすればよいのか」「SREを導入するにはどのように始めればいいのか」「
文化による成功: 失敗を受け入れることがなぜより良いソフトウェア デリバリーを促すのか | Google Cloud 公式ブログ
物事はうまくいかないものです。それが摂理です。物事が思いどおりに進まないとき、重要なのは次に何が起こるかです。 ※この投稿は米国時間 2023 年 10 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。 Google と Google の DevOps Research and Assessment（DORA）組織による内部調査によると、信頼の文化、つまり質問やリスクテイク、間違いを許容する文化を奨励するチームの方がパフォーマンスが上向くことがわかっています。機会に対しどのように応じるかということは、組織文化の重要な要素です。また、ソフトウェア デリバリーとチーム全体の効率においては、組織が障害にどのように対応するかが同様に重要となります。 復元力を促進する一定の行動や働き方を採用することで、チームの有効性を高め、組織のパフォーマンスを向上させることができま
「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由
OpenShift.Runで登壇した資料です。
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
入門 継続的デリバリー
継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 序文 はじめに 第1部 継続的デリバリーとは 1章 『入門 継続的デリバリー』へようこそ 1.1 継続的デリバリーは必要？ 1.2 なぜ継続的デリバリー？ 1.3 継続的デリバリーとは 1.4 インテグレーション 1.5 継続的インテグレーション 1.6 何をデリバリーするのか？ 1.7 デリバリー 1.8 継続的デリバリーと継続的デプロイメント 1.9 継続的デリバリー
「なんでも屋」は避けたいですか？なんでもできたら最強じゃないですか？：No SRE , No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ #SHIFT TECH TALKS#1 後記とQA補足 #SHIFT_SRE - 株式会社X-Tech5
Blog X-Tech5エンジニアがお送りするテックブログ SREやDevOpsをはじめ、インフラエンジニアリングの実践情報を届けします。 「なんでも屋」は避けたいですか？なんでもできたら最強じゃないですか？：No SRE , No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ #SHIFT TECH TALKS#1 後記とQA補足 #SHIFT_SRE 2024年4月2日 こんにちは。CTOの馬場（@netmarkjp）です。 2024年3月26日に TECH PLAY にて No SRE，No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ｜ #SHIFT TECH TALKS#1 が開催されました。 わたしはトップバッターとして『SREsのためのSRE定着ガイド』をお話しました。 ご質問を多数いただきまして、時間内にはすべては扱えず残念で
『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので…
リリース頻度を毎週から毎日にしてみた - NTT Communications Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
2024年のPlatform Engineeringはこうなる(なってほしい)
Forkwellさん主催の「今から予測する2024年のPlatform Engineering」で登壇した資料です https://forkwell.connpass.com/event/303922/
運用に携わる人全員に見てほしい！ Ops Guidesの紹介 - Qiita
PagerDuty Advent Calendarの8日目！ 今日はOps Guidesのお話です。 うちはこうだけど、他はどうやってるんだろう？ 普段から運用に関わっていると、ふとした瞬間に「そういえば他の会社ではどういう運用をやっているんだろう？」と気になること、ありませんか？ そのきっかけは「本当になんとなく」といったものから「上手くいかない運用にフラストレーションが溜まって」というどす黒いものまで色々あると思いますが、いずれにせよ「他の会社の良いところを取り入れて、自分たちの運用を改善したい」という気持ちから来ているのは間違いないでしょう。 だからこそ、いろんなミートアップに参加して発表を聞いたり、懇親会で話してみたり、Xに垂れ流されているいろんなポストを読んで事例を学ぶわけです。 ベストプラクティスを学びたい! このような取り組みはとても良いことですし、是非とも継続して情報収集し
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されたのでサマってみた
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。 ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。 ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。 それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。 本家のドキュメントはこちらです。ぜひお読みになってください。 DevOps Guidance 要約と紹介 最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。 面白い一文があったので引用します。 There is no one-size-fits-all
State of DevOps Report 2023 のまとめ
2023 年版の State of DevOps Report が公開されました。 State of DevOps Report とは Google の DevOps Research and Assessment（DORA）チームが毎年公開している DevOps や開発生産性にまつわる年次レポートです。 本記事で、今年のレポートの概要を簡単に見ていきたいと思います。 主な調査結果 Goodhart の法則を理解し、パフォーマンス向上の落とし穴を避ける 開発組織のパフォーマンスを評価する際、メトリクスの設定や評価の方法には注意が必要であり、特に「Goodhartの法則」という考え方を知っておくことが大切であると述べられています。 Goodhartの法則とは、簡単に言うと「測定が目標となると、それは良い測定基準でなくなる」という法則です。 この法則を踏まえた、パフォーマンスの評価や向上のため
2023 State of DevOps Reportを読んだ - 生涯未熟
今年もState of DevOps Reportが発表されましたね。ということで、ザザッと全体を読んで気になったところなどピックアップして読み解いてみました。 全文が気になる方は以下からPDFをダウンロードしてみてください。 cloud.google.com 今年の調査主軸 組織の業績 組織は収益だけでなく、顧客のため、さらに広範なコミュニティのために価値を生み出さなければならない チームパフォーマンス アプリケーションまたはサービスチームが価値を創造し、革新し、協力する能力 従業員の幸福 組織やチームが採用する戦略は、従業員にとって有益なものでなければならない。すなわち、燃え尽きを減らし、満足のいく仕事体験を育み、価値あるアウトプット（つまり生産性）を生み出す能力を高めることである。 今回は上記３つの成果達成に対しての調査となった。 調査結果短評 生成的な文化を持つチームは、組織のパフ
DevOpsの負の側面について
トランスクリプト Protsenko氏：私の名前はMykytaです。Netflixで働いています。私の仕事は基本的に、他の開発者が遅くまで職場に残らなくてもいいようにすることです。彼らが午後5時に退社しても生産的であることが私の実現したいことです。私はプラットフォーム組織、つまり生産性エンジニアリング部門で働いており、他のエンジニアのために労力を抽象化しようとしているのです。エンジニアが同じ退屈な技術的問題に何度も対処するのではなく、ビジネス上の問題の解決に集中できるようにします。 いくつか質問させてください。あなたたちのうち何人が、自分で作って自分で動かすという哲学を実践している会社で働いてますか？生産現場との間にゲートキーパーがいないこと、機能や修正をより早く提供できることに満足している人はどれくらいいますか？本番環境で発生したインシデントに対処しているときに、どうすればいいのか分から
SREはインフラエンジニアだけでなく、みんなの活動 - ytake blog
みなさんSREしてますか？ サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね？ 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場
Faster Pull Request Reviews 〜ハイパフォーマンスチームへの道〜 / Faster Pull Request Reviews
『ベストプラクティスから学ぶ！Four Keys向上へのトライ~夏の開発生産性LT Week~』の登壇資料です。 - イベントURL: https://findy.connpass.com/event/292030/
Broken Ownership
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity
入門EOL対応
アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai
