SREやクラウドエンジニアが読むと良さげな本まとめ - Qiita
一年半ぐらい前にアプリケーションエンジニアからSREにコンバートした筆者が、いま役に立ってるなぁっていう本を紹介します。アプリケーションコードを書いてるときは下のレイヤの技術に興味なかったんですが、改めて勉強してみると楽しいです。 コンピュータシステム クラウド全盛とはいえ、コンピュータの仕組みはおさえておくと役立ちます。コレ系の本はわりと小難しいものが多いですが、個人的に楽しく読めた本を紹介します。 Raspberry Piで学ぶコンピュータアーキテクチャ Raspberry Piと銘打たれてますが、コンピュータアーキテクチャの歴史的な背景も踏まえて解説されています。プロセッサ・メモリ・ストレージ・ネットワーク・OS・プログラミングなど、コンピュータ単体の基本的な知識を学べます。 歴史をあわせて知ることができるため、知的好奇心がおおいに刺激され、楽しく読むことができます。この本が難しく感
ホストのプロビジョニングを Chef から mitamae へ移行した - KAYAC engineers' blog
SRE チームの藤原です。Tech KAYAC Advent Calendar 2019 Upgrade/Migration track 6日目の記事です。 今日は長らく EC2 などのホストのプロビジョニングに利用していた Chef を、mitamae に移行したお話です。 Chef とその管理 Chef といえば、Infrastructure as a Code という概念を広めた先駆者ともいえるソフトウェアです。Ruby DSL でホスト上のファイルやパッケージなどの様々なリソースを宣言的にプロビジョニングできる、界隈では大変おなじみの奴ですね。 カヤックでも自分が入社した2011年から Chef によるプロビジョニングを行ってきて、もう8年になります。 多くのプロジェクトではアプリケーションとは切り離した、その名も "chef" という名前の GitHub リポジトリにコードや設定
Google - Site Reliability Engineering
Written by: Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In
2019年SRE考 - ゆううきブログ
この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちに、SREに関する私的な論考をまとめておく。 (以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。) SREとの関わり なぜSREに関心をもったのか 2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニア、インフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SRE
SRE風のインフラエンジニアにならないために - Work Records
この記事は、SRE Advent Calendar 2018 - Qiitaの24日目として投稿しています。 SRE風のインフラエンジニア SREとDevOps そもそもDevOpsとは SRE本でも取り上げられている、DevとOpsの目的の差異 ミクロなDevの目的 ミクロなOpsの目的 Ops側の視点での安定性の考え方を改める システムを高速に更新可能にしておくことで安定性を担保する インフラエンジニアではなくSREとしてどう高速リリースを実現するか プロダクトの高速リリースに効くところを見極める リリースするにあたっての心配事を潰す 開発チームが自律して動ける仕組みやツールを提供する 今の組織でやれていること 開発チーム出身の人がSREチームにジョインしてくれている SREチームに入る新人のエンジニアさんもRails研修などを通して最低限の開発力を持っている SREチームのケツを叩い
hbstudy#74 SRE大全：序章 活動報告
はじめまして、入社5年目、新卒2年目アイドル部部長兼運用エンジニアの阿部（ @abnoumaru ）です。 2017年07月25日に開催された「hbstudy#74 SRE大全：序章」の活動報告です。 なぜ SRE 本の勉強会を開催したか Googleが"Site Reliability Engineering"（SRE）を提唱した後、 その手法は世界中で瞬く間に広まり、日本でも"SRE"の名前が付くチームを持つ会社が増えています。Web サービスを中心としたインフラを担当するハートビーツにとってもSREを専門職としてはいないものの、現在行なっている業務に近しい分野です。 そこで、hbstudyではSRE大全と題して、様々なSREの話を聞くべくシリーズで勉強会を開始します。今回は、 2017年8月12日に発売される『SRE サイトリライアビリティエンジニアリング --Googleの信頼性を
SRE との “壁” を取り除くには : CRE が現場で学んだこと | Google Cloud 公式ブログ
今回の連載記事のパート 2 では、サービスのサポートを引き継ぐにあたって SRE チームが知りたいことは何なのか、引き継ぎまでにサービスをどう改善してほしいと考えているのかを説明しました。また、パート 1 では SRE が新しいアプリケーションを担当する（または担当しない）と判断するときの理由を挙げました。今回は、ページャーを担当することになった SRE とのやり取りについて見ていきましょう。 サポート担当の準備 サービスの事前レビューで SRE によるサポートが適当だと判断された場合、開発者と SRE チームはサポートの開始に向けて準備を行う “onboarding” のフェーズに移行します。 このフェーズでは、開発者はやるべきことに対処し、SRE チームはサービスについて学び始めます。サービスに関する知識を身につけ、既存のモニタリング ツールやアラート、危機対処法などを学ぶのです。その
[翻訳]サイト信頼性エンジニアリング (SRE) とは何か？ - Qiita
本稿は以下で公開されている Ben Treynor 氏と Niall Murphy 氏のインタビュー記事の翻訳です。 https://landing.google.com/sre/interview/ben-treynor.html 免責事項/Disclaimer 本稿は 非公式 の翻訳記事です。インタビュアーの Niall Murphy 氏 (@niallm) に翻訳を公開することの許可は取っています。本稿の内容に関して Niall Murphy 氏と Google 社は一切の責任を負いません。 Japanese version of the Ben Treynor Sloss interview; thanks @t2y_en 4:33 PM - 27 Jan 2017 誤訳などありましたら私宛に編集リクエストを送って頂けると助かります。 補足事項 本文中に英文で引用しているところは、
![[翻訳]サイト信頼性エンジニアリング (SRE) とは何か？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/24693479847097814f977e88ca2247a9a75ef178/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJUUzJTgyJUI1JUUzJTgyJUE0JUUzJTgzJTg4JUU0JUJGJUExJUU5JUEwJUJDJUU2JTgwJUE3JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgyJUI4JUUzJTgzJThCJUUzJTgyJUEyJUUzJTgzJUFBJUUzJTgzJUIzJUUzJTgyJUIwJTIwJTI4U1JFJTI5JTIwJUUzJTgxJUE4JUUzJTgxJUFGJUU0JUJEJTk1JUUzJTgxJThCJUVGJUJDJTlGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1mMWQxYzM0OTExMGYzOWFkZjQzMzY1NzkzMjdhYWQ2OA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0MnkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTIwYWMxYTI2M2ZlOTJjZTE1NDhiMTZiMmI4ZjYwNmFk%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dba32cd128ea8dbb74c3313a20ae46233)
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ 「Site Reliability Engineering」（SRE）とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 これまでの運用チームやインフラチームによる運用や改善とSREが異なるのは、SREでは積極的にコードを書き、ソフトウェアによって目的の達成を目指している点にあるといえます。 Googleが公開しているSREのWebサイトでは、SREを次のように説明しています。 Like traditional operations groups, we keep important, revenue-critical syst
Books For Site Reliability Engineering
By: Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In this bo
SRE チームを設立します - Cybozu Inside Out | サイボウズエンジニアのブログ
運用本部長を務めている山本泰宇です。 運用本部は社内の情報システムを担当する情報システム部と cybozu.com など自社クラウドサービスを運用するサービス運用部からなる部門です。 本日、サービス運用部にて SRE チームを設立しました。この記事ではチーム設立にいたった経緯と今後の活動計画を紹介いたします。 Site Reliability Engineering (SRE) とは 今年の 3 月に O'Reilly から出版された "Site Reliability Engineering" で有名になりましたが、Google のプロダクトやサイトを安定運用するための活動やその活動に従事する人・チームを指します。特徴としては基本的にソフトウェアエンジニアからなる集まりで、自律的な仕組みや自動化を日常的に行っていることです。 サイボウズでも 5 月から社内で SRE 本の輪講を開催し、理
マイクロサービスとSRECon / #microserv
8/9 に FiNC 社で開催された Microservices Meetup vol.2 で、マイクロサービスと SRECon という話をしました。
書評: Site Reliability Engineering
英語だけどぜひ読んでほしい Site Reliability Engineering: How Google Runs Production Systems 参考になったのでご紹介。Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本です。GoogleのSREについては断片的に知っていたのですが、まとめて読むと違いますね。背景やストーリーがあって、理解しやすいです。 共感できるネタがどんどん繰り出されるので、一気読みしました。読み込みが浅いところもあったので、改めて読む予定。 以下、印象に残ったこと。 Site Reliability Engineering teamは、インフラ/Ops担当であるが、Unix内部やネットワークなどインフラの知見を持つソフトウェアエンジニアの集団。自分たちのオペレーションを効率的に、迅速に、確実にするために、コードを書く。 インシデント対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleが解説 - 他社のSRE実践はなぜ誤りなのか
運用現場におけるSRE本の「正しい」読み方
SREグループができてこの半年間やってきたこと
On-call Engineering
Site::Reliability::Engineering - YAPC::Hakkaido 2016 Sapporo