このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
strace でプログラムの動きを追ってみよう | SIOS Tech. Lab
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました 生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!! https://tech-lab.connpass.com/event/315703/ 【5/27開催】事業変革を最新ソフトウェア技術で加速する「OSS利活用事例セミナー」 OSSのビジネス活用事例などを紹介します！登壇者はスカパー様やIPAなど🎤 OSSを活用した新たなビジネス創出やDX推進のヒント
AndroidチームのIDE警告ゼロへの取り組み - Mirrativ Tech Blog
こんにちは。エンジニアのshogo4405です。普段は、ミラティブで開発しながら、余暇にOSSのHaishinKit*1*2をつくっています。本稿では、Androidチームで取り組んだAndroid Studioから出てくる警告対応ゼロの仕組み化について紹介します。 はじめに 筆者は、警告は一つ一つ適切なアクションを行うべき対象と考えています。警告一つ一つに意味を持っています。リリース後にクラッシュレポートを見て「あー警告」で指摘されてたという失敗経験もあります。チーム開発においては、IDEの警告ゼロが当然になるように働かきかけています。 Androidチームでは、2021年第3四半期のOKRの一つとして警告ゼロ対応を掲げました。着手当初は278 warnings, 306 weak warnings, 75 infosの警告等がありました。 ゼロ警告へのアプローチ まず初めにチームで実施
メルペイSREチームのこれまでとこれから | メルカリエンジニアリング
こんにちは、メルペイSREでEngineering Managerをしている @tjun です。 この記事は Merpay Tech Openness Month 2021 1日目の記事です。 以前SRE NextでSREチームの話をしたのですが、その後の話を発表するちょうどいい場がなかったのでblogとして書くことにしました。チームとしてはまだまだ道半ばですが、この記事がこれからSREチームを作っていく人の参考になったらいいなと思います。 はじめに SREとは？ SREのあり方は、組織やシステムの規模やアーキテクチャ、扱うサービスによって変わると思います。SRE本はもちろん参考にするのですが、Googleのやり方が自分たちの会社でそのまま上手くいくとは限らないので、根っこの部分の考え方や文化を参考にしながら、実践の方法は自分たちの組織に合わせて適用していく必要があります。 SREって何？
ごく普通のエンジニアリング運用チームを強力な SRE チームに変える | Google Cloud 公式ブログ
※この投稿は米国時間 2019 年 10 月 4 日に Google Cloud blog に投稿されたものの抄訳です。 運用チームにエンジニアを絶えず増員しても、お客様の拡大には対処しきれません。Google のサイト信頼性エンジニアリング（SRE）の原則を適用すれば、運用上の問題にソフトウェア エンジニアリングによる解決手法を取り入れることで、うまく対処できます。本稿では、従来のネットワーク エンジニアリングの通例にとらわれず、SRE に転換することで、Google がグローバル ネットワーク運用チームを変革した方法をご紹介します。Google の本番環境ネットワーキング チームがこの問題にどのように取り組んだのかをお読みいただき、ご自分の組織に SRE の原則をどのように取り入れることができるのかを検討してみてください。 スケーリングの限界2011 年、Google の本番環境ネット
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編） | DevelopersIO
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編） はじめに 本記事は、全９回の SRE 社内勉強会のアウトプットとして執筆したブログの後編となります。 前編をお読みでない読者の方がおられましたら、是非前編もご一読ください。 ５章 トイル（労苦）の撲滅 「通常運用中のシステムに人手が必要なら、それはバグだ。通常の定義は、システムの成長と共に変化する。」 トイルを減らしサービスをスケールさせる作業こそが SRE における「エンジニアリング」である点を説明しています。聞き慣れない言葉ですが、トイルとは何でしょうか？ここでは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向をもつものと述べられています。例えば
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（前編） | DevelopersIO
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（前編） はじめに 筆者が入社した直後 2017/4 吉日に、弊社 IT 推進室長の植木（当時、オペレーションチームの部長）が「SRE 勉強会するよ」という発言に端を欲し各自英語版を翻訳した資料を持ち寄り全９回の SRE 勉強会が 2017/5/11 より開始されました。本勉強会のアウトプットとして、本ブログを執筆します。 なお、本ブログ記事はSRE 勉強会の対象となった第１章〜第９章まで（第２章を除く）を要約した形でお届けし、SRE を知るきっかけとなれば幸いであると考えております。そのため、興味をお持ち頂いた読者の方々は下記のオンライン本もしくは翻訳本のいずれかをお手に取って頂き、その詳細について学んで頂ければと思います。 SRE とは 誤解を恐れずにざっくり説明すると、以下になります。
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
Google - Site Reliability Engineering
What is Site Reliability Engineering (SRE)? SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and cap
Googleが解説 - 他社のSRE実践はなぜ誤りなのか
GoogleのCRE(Customer Reliability Engineer)であるStephen Thorne氏が先日のDevOps Enterprise Summit Londonで講演し、SRE(Site Reliability Engineering)とは何か、その基本的な前提とメリットを理解できていない組織がいかに多いか、などについて解説した[スライドのPDF]。氏がこれまでに他の組織で見たおもな誤解は、早期の障害検出に重点を置いたSLO(Service Level Objective)や、あるいは過去のインシデントの金銭的保証に使用するSLA(Service Level Agreement)との混同、エラー予算を執行しない、SREチームの活動の少なくとも50パーセントをシステムやツールの改善に費やさず、“消防活動”という名の運用上の苦役に没頭させる、といったものだ。 SLO
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もしSIerのエンジニアがSRE本を読んだら
kazeburo (@kazeburo) on Speaker Deck
Cloud connect the world as a Glue - AWS Dev Day 2017