Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 一年半ぐらい前にアプリケーションエンジニアからSREにコンバートした筆者が、いま役に立ってるなぁっていう本を紹介します。アプリケーションコードを書いてるときは下のレイヤの技術に興味なかったんですが、改めて勉強してみると楽しいです。 コンピュータシステム クラウド全盛とはいえ、コンピュータの仕組みはおさえておくと役立ちます。コレ系の本はわりと小難しいものが多いですが、個人的に楽しく読めた本を紹介します。 Raspberry Piで学ぶコンピュータアーキテクチャ Raspberry Piと銘打たれてますが、コンピュータアーキテクチャの歴史的
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 リポジトリにコードや設定
この記事では、自分が数年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 Advent Calendar 2018 - Qiitaの24日目として投稿しています。 SRE風のインフラエンジニア SREとDevOps そもそもDevOpsとは SRE本でも取り上げられている、DevとOpsの目的の差異 ミクロなDevの目的 ミクロなOpsの目的 Ops側の視点での安定性の考え方を改める システムを高速に更新可能にしておくことで安定性を担保する インフラエンジニアではなくSREとしてどう高速リリースを実現するか プロダクトの高速リリースに効くところを見極める リリースするにあたっての心配事を潰す 開発チームが自律して動ける仕組みやツールを提供する 今の組織でやれていること 開発チーム出身の人がSREチームにジョインしてくれている SREチームに入る新人のエンジニアさんもRails研修などを通して最低限の開発力を持っている 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の信頼性を支
今回の連載記事のパート 2 では、サービスのサポートを引き継ぐにあたって SRE チームが知りたいことは何なのか、引き継ぎまでにサービスをどう改善してほしいと考えているのかを説明しました。また、パート 1 では SRE が新しいアプリケーションを担当する（または担当しない）と判断するときの理由を挙げました。今回は、ページャーを担当することになった SRE とのやり取りについて見ていきましょう。 サポート担当の準備 サービスの事前レビューで SRE によるサポートが適当だと判断された場合、開発者と SRE チームはサポートの開始に向けて準備を行う “onboarding” のフェーズに移行します。 このフェーズでは、開発者はやるべきことに対処し、SRE チームはサービスについて学び始めます。サービスに関する知識を身につけ、既存のモニタリング ツールやアラート、危機対処法などを学ぶのです。その
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本稿は以下で公開されている Ben Treynor 氏と Niall Murphy 氏のインタビュー記事の翻訳です。 https://landing.google.com/sre/interview/ben-treynor.html 免責事項/Disclaimer 本稿は 非公式 の翻訳記事です。インタビュアーの Niall Murphy 氏 (@niallm) に翻訳を公開することの許可は取っています。本稿の内容に関して Niall Murphy 氏と Google 社は一切の責任を負いません。 Japanese version of
![[翻訳]サイト信頼性エンジニアリング (SRE) とは何か？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ee5bb4835a046c0dffd00e39a647c9998ea79127/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.1.1%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnMzLWFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkZxaWl0YS1pbWFnZS1zdG9yZSUyRjAlMkY1OTg4JTJGY2VkYWI4MzM1MDcyMzE3YTBkN2U4YTI5NDc0M2Y4OTlmMjc2NzlkOSUyRmxhcmdlLnBuZyUzRjE1NzE5MDEzMDI_aXhsaWI9cmItNC4xLjEmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmJnPUZGRkZGRiZmbT1wbmczMiZzPTRkODkwYTY0ODMwNTQyMDk4NmM5MmUwMGRhNzI3NmJk%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Ddb5df280196000bb295093530cd010ff%3Fixlib%3Drb-4.1.1%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjEuMSZ3PTk2MCZoPTMyNCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJUUzJTgyJUI1JUUzJTgyJUE0JUUzJTgzJTg4JUU0JUJGJUExJUU5JUEwJUJDJUU2JTgwJUE3JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgyJUI4JUUzJTgzJThCJUUzJTgyJUEyJUUzJTgzJUFBJUUzJTgzJUIzJUUzJTgyJUIwJTIwJTI4U1JFJTI5JTIwJUUzJTgxJUE4JUUzJTgxJUFGJUU0JUJEJTk1JUUzJTgxJThCJUVGJUJDJTlGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9OWI2Mzg2NGEzOWMyODRiYTc1ZjFlMWM5MmY5NzMxN2M%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjEuMSZ3PTgzOCZoPTU4JnR4dD0lNDB0MnkmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz1jMzI4MTBhMmFjYjgwN2JlN2MzZGZmOGI4Y2MzOWFiNQ%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D01d64ab0c6c1ec89cd5c179d2c314493)
先日、NTT Tech Conferenceに参加しました。そこで、DevOpsのセッションを聞いて色々と思うところがあったので、手持ちの資料から抜粋して色々と書いてみます。 大本の資料は、2013から2015年にかけて、九州工業大学でM1の学生向けに講演した内容になります。 今思えば、「ベンチャー企業におけるDevOpsについて話してほしい」という依頼に対して、「DevOpsと社内政治」について話してしまったので、本当に申し訳ないと思ってる。 まあ、ツールはいくらでも移り変わるが根源の思想はどこまで行っても変わらんので、思想教育だけしておけばいいかなというのはある。 さて、昨今DevOpsが話題で、「DevOpsをやってみたいので、どのツールを使ったらいいか教えてくれ」みたいな残念な会話をチラホラ耳にします（と、NTTの中の人が言ってしました）。 この手の人々が残念なのは、DevOps云
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
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
運用本部長を務めている山本泰宇です。 運用本部は社内の情報システムを担当する情報システム部と cybozu.com など自社クラウドサービスを運用するサービス運用部からなる部門です。 本日、サービス運用部にて SRE チームを設立しました。この記事ではチーム設立にいたった経緯と今後の活動計画を紹介いたします。 Site Reliability Engineering (SRE) とは 今年の 3 月に O'Reilly から出版された "Site Reliability Engineering" で有名になりましたが、Google のプロダクトやサイトを安定運用するための活動やその活動に従事する人・チームを指します。特徴としては基本的にソフトウェアエンジニアからなる集まりで、自律的な仕組みや自動化を日常的に行っていることです。 サイボウズでも 5 月から社内で SRE 本の輪講を開催し、理
8/9 に FiNC 社で開催された Microservices Meetup vol.2 で、マイクロサービスと SRECon という話をしました。
英語だけどぜひ読んでほしい Site Reliability Engineering: How Google Runs Production Systems 参考になったのでご紹介。Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本です。GoogleのSREについては断片的に知っていたのですが、まとめて読むと違いますね。背景やストーリーがあって、理解しやすいです。 共感できるネタがどんどん繰り出されるので、一気読みしました。読み込みが浅いところもあったので、改めて読む予定。 以下、印象に残ったこと。 Site Reliability Engineering teamは、インフラ/Ops担当であるが、Unix内部やネットワークなどインフラの知見を持つソフトウェアエンジニアの集団。自分たちのオペレーションを効率的に、迅速に、確実にするために、コードを書く。 インシデント対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
