最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon この本では、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根本対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない！」「障害対応をもっとうまくやる方法はないのだろうか？」と思う人には参考になる部分が多いと思う。 個人的にこの本の中で一番良いなと思ったのは、 SREだけでなくアプリケーションエ
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
SRE 研修
SRE 研修 共有ログインお使いのブラウザのバージョンはサポートが終了しました。 サポートされているブラウザにアップグレードしてください。閉じる ファイル編集表示ツールヘルプユーザー補助機能デバッグ
英語だけどぜひ読んでほしい Site Reliability Engineering: How Google Runs Production Systems 参考になったのでご紹介。Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本です。GoogleのSREについては断片的に知っていたのですが、まとめて読むと違いますね。背景やストーリーがあって、理解しやすいです。 共感できるネタがどんどん繰り出されるので、一気読みしました。読み込みが浅いところもあったので、改めて読む予定。 以下、印象に残ったこと。 Site Reliability Engineering teamは、インフラ/Ops担当であるが、Unix内部やネットワークなどインフラの知見を持つソフトウェアエンジニアの集団。自分たちのオペレーションを効率的に、迅速に、確実にするために、コードを書く。 インシデント対
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 - エンジニアHub｜Webエンジニアのキャリアを考える！
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 SREの役割には、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといった複数のキーワードが存在するがゆえ、なかなかうまく実践できない、という声もあります。本稿では、難しく見られがちなSREの内実を、「信頼性の制御」というコンセプトを軸に整理し、小さく始める一歩を坪内佑樹（ゆううき）さんが解説します。 こんにちは。SREの研究者をやっているゆううき（@yuuk1t）です。 SRE（Site Reliability Engineering）は、従来のオペレーションエンジニア、システム管理者（sysadmin）と呼ばれる人々が担っていた技術領域の新しい形です。Googleによって提唱され、日本国内でも2015年ごろからWebコンテンツ事業者のコミュニティを中心に広く知られる
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告 3月13日の11時53分から15時13分（いずれも日本時間）までの3時間20分のあいだ、GmailやGoogle Drive、Google Photos、Google Storage、App EngineのBlobstore APIなどGoogleの広範囲なサービスで一部の機能が利用できなくなる、あるいは遅延が発生するなどの障害が発生しました。 その原因と対策について、Googleが「Google Cloud Status Dashboardのインシデント#19002」として報告しています。 報告では障害の原因が、ストレージ内のリソースを削減しようとしたSRE（Site Reliability Engineer）による構成変更にあったと説明。 SRE（Site Reliabili
障害発生！全員集合？ － オンコールアンチパターンからの一歩前進 - Cybozu Inside Out | サイボウズエンジニアのブログ
8月だというのに涼しい日が続きますね。 kintone.comのDevOpsをしている@ueokandeです。 もうすぐAWS版kintoneのローンチからから2年が経過しようとしています。 この2年間、DevOpsチームではkintone.comのサービス安定化やスケーラビリティに注力してきました。 時には本番環境の障害で休日や深夜に障害対応することもあります。 kintone.comの障害の一次対応は、我々DevOpsメンバーが実施しています。 サービスローンチ直後は、メンバーの多くがオンコールに不慣れで、慌てて障害対応したりうまく進められないことが何度もありました。 そこでメンバー全員が効率的・効果的な障害対応を目指すべく、チームでPagerDuty社のIncident Response（非公式日本語訳版）を読むことにしました。 この記事ではAWS版kintoneで実際に体験した障害
カオスエンジニアリングを組織にも適用。アンチフラジャイルなシステムを目指してユーザベースが発見した問題とは？ - はてなニュース
Netflixがシステム運用に取り入れている、カオスエンジニアリング（chaos engineering）という手法があります。例えば機能を冗長化したシステムでも、いざ障害が起きたときに別系統が想定どおり機能するか分からない。そこで実際に動いているシステムで意図的に障害を起こし、挙動を確認してシステムの改善につなげる考え方です。 株式会社ユーザベースでは、アンチフラジャイル（antifragile、反脆弱）なシステムを目指してカオスエンジニアリングを導入しています。システムだけでなく、エンジニア組織においてもカオスエンジニアリングを応用した改善プロセスに着手しています。キーパーソンがいなくなってもプロジェクトはうまく動き続けるか、実際に外れてもらって確認するのです。 このチャレンジングな取り組みについて、CTOの林尚之さんと、システムでも組織でもカオスエンジニアリングを体験したエンジニアの
SREの@deeeetです。 新しい機能を素早くリリースしフィードバックを得てすぐにPivotの決定を行う、もしくはリスクを抑え小さな改善を継続的に行うContinuous Deliveryはソフトウェア開発において非常に重要です。 メルカリではこのContinuous DeliveryのためのPlatformにSpinnakerを採用し始めました。現在は主にkubernetes（k8s）へのコンテナアプリケーションのDeployに利用しており、既にいくつかの本番アプリケーションがSpinnakerによりDeployされています。 本記事ではなぜSpinnakerを採用したか、Spinnakerとは何か、実際にメルカリでどのようにSpinnakerを使っているか、について簡単な紹介をします。 kubernetes上でのDeploy問題 k8sへのコンテナイメージのDeployは非常に簡単で
はじめに 最近、ビジネスダッシュボードの設計・実装ガイドブックという書籍が出版された。今まであまりなかった視点から書かれたデータに関する本で面白く読んだ。 ビジネスダッシュボード 設計・実装ガイドブック 成果を生み出すデータと分析のデザイン 作者:トレジャーデータ,池田 俊介,藤井 温子,櫻井 将允,花岡 明翔泳社Amazon 作ったダッシュボードの利用が進まず、虚しさを覚えた経験がある人は多いと思う。どうしてそうなってしまうのか、自分の経験を元にまとめたいなと思ったのでまとめる。 なぜ使われないダッシュボードが作られるか なぜ作られたダッシュボードが使われないかと言うと、基本的にはそのダッシュボードがそんなに必要なものではないからだ（社内周知がうまくない、ツールの使い方がわからない人が多いなどの理由もあったりするがここでは無視する）。 必要のないダッシュボードが作られてしまう状況に関して
筋肉マージは辞めよう - Qiita
追記2 2019/12/04 21:00 こんなよくわからない記事をご覧いただきありがとうございます。 この事件を起こしたのは1年前で、Gitを使いはじめて1ヶ月のときに下記の事件を起こしてしまっていてとても混乱していたのを当時覚えています。 内容については、rmをしたかもしれないという記事に結果的になったかもしれませんが、私の記憶ではファイルを消した記憶はありません。 ただ、当時作業していたディレクトリもないのでコマンドを確認する手段がないため一番濃厚なrmをしたというのを今回の結論にしました。 曖昧さは申し訳ありません。 また、意見、感想、批評には全て目を通させております。伝わりにくい内容やわかった事実は適宜編集してできるだけ皆さんに伝わるよう善処いたしますのでどうぞよろしくお願いします。 追記2ここまで 追記 2019/12/04 13:00 1.本番環境でやらかしちゃった人 Adv
Google、SRE本の第三弾「Building Secure and Reliable Systems」を無料公開
Google、SRE本の第三弾「Building Secure and Reliable Systems」を無料公開 GoogleはSite Reliability Engineering（SRE）に関連する書籍として、これまで「Site Reliability Engineering」「The Site Reliability Workbook」の2冊を無料で公開してきました。 このSRE本の第三弾として、Googleは「Building Secure and Reliable Systems」の無料公開を開始しました。 「Site Reliability Engineering」（SRE）とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 そしてこのアプローチは、前述の通り20
みなさん、監視作ってますか？ システムを作ったら、そのシステムを監視していく必要がありますよね。どうやったら「いい監視」が作れるのでしょうか。「いい監視」とそうでない監視との違いとは、いったいなんでしょうか。 今の時代、「監視」ではなくて「可観測性」、 Observability (o11y) の時代になっていて、良いプラクティスや考え方が色々とあります。 この記事は、監視や o11y についての考え方を社内に共有するため書いたものを、社外共有用に調整し直したものです。新しい Observability の時代を、一緒に生きていきましょう。 監視を作ろう あなたはシステムを作りました。そのシステムに「監視」をつけようと思ったとき、最初にすることはなんでしょうか？ まずは、システムを何らかのツールで監視するところから始めましょう。やらなきゃはじまらない。 Nagios, Cacti, Mun
メルカリ新卒エンジニアはSREもサポートも経験する！ BABAROT Hiraku インタビュー｜ハイクラス転職・求人情報サイト AMBI（アンビ）
メルカリ新卒エンジニアはSREもサポートも経験する！ BABAROT Hiraku インタビュー フリマアプリ「メルカリ」で、若手Webエンジニアはどんな活躍をしているのか。メンターによる育成の様子も交えてお送りします。 若手エンジニアのための情報メディア「エンジニアHub」がスタートしました！ 本連載「若手エンジニア、どんな活躍してますか？」では、若手エンジニアが企業でどんなふうに働いているか、会社やメンターはどんなことを考えて育成しているかを探っていきます。 ── 第1回はフリマアプリ「メルカリ」！ 急拡大中の企業で、若手エンジニアはどんなふうに開発に携わっているのでしょうか。ということで、まずは自己紹介をお願いします。 BABAROT 初めまして、BABAROT (@b4b4r07 / id:b4b4r07) こと石山将来です。メルカリでサーバサイドエンジニアとして働いています。2
Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
Talked at CloudNative Days Tokyo 2020 #CNDT2020. Video available at https://event.cloudnativedays.jp/cndt2020/talks/30
Istio導入のメリットとハマりどころを、実例に学ぶ～マイクロサービス化の先にある課題を解決する｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Istio導入のメリットとハマりどころを、実例に学ぶ～マイクロサービス化の先にある課題を解決する マイクロサービス化にともなサービス間の接続の複雑化、という課題への対処としてサービスメッシュとこれをもたらす「Istio」が注目されています。Istioをいち早く導入したユーザベースの阿南さんが、導入メリットと、使って分かった「ハマりどころ」を解説してくれました。 マイクロサービスを増やしていくならサービスメッシュ化を検討すべき KubernetesやIstioは今までの技術の集大成 運用したからこそわかるIstioのハマりポイント ハマりどころ1：設定の反映が遅延する ハマりどころ2：エンドポイント登録がnamespase単位で分かれていない ハマりどころ3：istio-proxyの制限にひっかかる 使っている人に聞いてみた「Istio-proxyを経由すると10ms遅くなる？」 Istio
Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）
Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
オブザーバビリティ研修実践編
株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編（一部社内向けの内容）
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
Copyright © 2017 Google, Inc. Published by O'Reilly Media, Inc. Licensed under CC BY-NC-ND 4.0
第40回インターネットと運用技術研究発表会の招待講演で『Web サービスの信頼性と運用の自動化について』というタイトルで発表しました。
Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。 - MonotaRO Tech Blog
序文 こんにちは。MonotaROの伊藤です。 弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います 序文 運用担当者の負荷が高まり続ける問題 運用担当者=社歴が長いベテランエンジニア 運用のスケールアウト 障害対応訓練をやってみよう 訓練環境の準備の問題 訓練シナリオの問題 外部からの助け Wheel of Misfortuneとは 実施時の様子 シナリオ開始時の様子 モニタリング画面の表示 WoMとDiRT(Disaster in Recovery Training) 障害対応訓練をやってみた結果 準備時点で感じたメリット 手順書の不備を発見できたこと 障害が起こりかねない場所を考えるきっかけになったこと
システム運用の現場でしか学べないことは他メンバーに積極的に経験してもらうべきだった - seri::diary
基本的に自分はタスクを拾いすぎてしまう傾向にある。それに加えて比較的朝型なこともあり、前職ではエンジニアの中で一番朝早く出社していることも多かった。*1 その結果どうなるかというと、朝出社して見つけた運用上のトラブルは大体自分がとりあえず手を付ける状態になっていた。前日の夜間バッチやその日の早朝に動くバッチがコケて問い合わせが来ているのでそのリカバリをする、前日にデプロイした後レスポンスが高くなってアラートが出ているのでその調査をする、web appがやたらと500系エラーを吐いているのでBugsnagを見る、等々。 出社している以上無視するわけにもいかないというのもあるが、見つけてしまうと放っておけない性格ということもあり最優先でこれらの対応をしてしまっていた。お陰で前職で触っていたproductについてはかなり広範囲の知見があり、その行動がそれなりに社内での評価につながっていたのではな
SmartNewsのサーバーサイドのすべて 大規模サービスを支えるアーキテクチャと技術スタック サーバサイドの技術スタック・アーキテクチャ総ざらい 2019年5月28日、「SmartNews Tech Night in Fukuoka Vol.1」が開催されました。日米4,000万ダウンロード (※1)を超えるニュースアプリ「SmartNews」の今と、技術にまつわる裏側について包み隠さず語る本イベント。プレゼンテーション「サーバーサイドの技術スタック・アーキテクチャ総ざらい」に登壇したのは、SREチームのEngineering Managerを務めるNobutoshi Ogata氏。SREチームの立ち上げを行い、EMとして活躍する同氏が、SmartNewsに用いられるサーバーサイドの技術について明かします。※1:日米Google Play、App Storeのダウンロード数を合算した数値
Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
GitHubの運用を「会社」にしていく話
Ubie DiscoveryでSREなどをしている@itkqです。 UbieではGitホスティングにgithub.comを使っています。プロダクト開発に必要なprivateなコードベースはもちろん、OSSや就業規則といったドキュメントをpublicにホストしたりもしています。また、この記事を書いている時点で、メインのOrganizationのメンバーは121名です。 自分が入社したのは一年前（2021年1月）で、まだ情報システム専任の人がいませんでした。それから今に至るまで、GitHubの運用を「会社」にしていく話を書きます。 一年前のGitHubの運用 当時、UbieのOrganizationに所属していた人数は、業務委託含め80〜90名ぐらいで、Businessプランを利用していました。私はSREとして入社しましたが、情報システム専任の人がおらず、SREをはじめとする何名かのメンバーが
みなさんSREしてますか？ サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね？ 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場
1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来｜ハイクラス転職・求人情報サイト AMBI（アンビ）
1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来 Kubernetesの設計思想に共感して、1,000台規模のインフラ刷新プロジェクトに採用したサイボウズが、独自のインフラ、自社開発のOSSツールで挑戦するNoOpsな未来について聞きました。 1,000台規模のインフラをKubernetesで刷新する なぜパブリッククラウドではなく独自インフラなのか インフラ自体を継続的デリバリするためツールをOSSで Kubernetesの設計思想にインスパイアされたNeco ビジネスとして大切にしている部分は細部まで自分たちで 主力製品の「サイボウズ Office」「Garoon」「kintone」などを、2011年からクラウドサービス cybozu.com として提供してきたサイボウズ。これらのサービスのために同社が自前で構築したインフラ基盤は、国
オブザーバビリティ（可観測性）がなぜ必要だと考えるのか - YAMAGUCHI::weblog
はじめに こんにちは、Stackdriver担当者です。本記事は完全に個人の意見です。（念押し） GCP的に担当製品がわかりやすいのでStackdriverの担当と書いてますが、仕事での担当領域的には「オブザーバビリティ (Observability、可観測性)」 です。この「オブザーバビリティ」という言葉が近年SREの文脈で語られることが増え、また今年に入って「入門 監視 ("Practical Monitoring" の日本語訳)」が刊行されたことで、日本でもより多く耳にするようになりました。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 発売日: 2017/08/12メディア: 単行本（ソフトカバー） 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julian発売日: 2019/01/17メディア:
待望の日本語版発売！『詳解システムパフォーマンス 第2版』Linuxが深く学べる名著を全力で推したい - LIVESENSE ENGINEER BLOG
こんにちは、かたいなかです。 『詳解システムパフォーマンス 第2版』の日本語版が2023/01/24についに発売されました！ www.oreilly.co.jp 私個人は原著で読んだのですが、他の人に強くおすすめしたくなるような内容でした。そこで、日本語版の発売に合わせてどのあたりが良かったのかなど、内容をご紹介します。 TL;DR パフォーマンス改善タスクの課題感 どんな本？ この本のどこがいい？ Linuxの仕組みを広く深く学べる パフォーマンスの観点での情報が豊富 どんなひとにおすすめできるか？ クラウドやコンテナが当たり前になってからSREになった人 Linuxの知識をアップデートしたいエンジニア 最後まで読み切るには？ あせらずゆっくり読んでいく Linuxの前提知識を仕入れてから読む 終わりに TL;DR 『詳解システムパフォーマンス 第2版』は、Linuxを深く学んで仕事に活
Kubernetes導入で実現したい世界とその先にあるMicroservices - スタディサプリ Product Team Blog
はじめに CTO兼SREエンジニアリングマネージャーの中野です。ここしばらくの間、CTO/SREエンジニアリングマネージャーとして注力しているKubernetes導入について紹介したいと思います。 今回は、Kubernetes自体がどういうものなのかということより、それをツールとしてどう使い、それでどういう世界を実現したいのかみたいなところを中心に紹介できたらと思います。 まず現在の状況ですが、Quipperでは、大きく分けてスタディサプリの小中高校生向けと日本以外向けの2つのサービスを展開しています。サービスとしての構成はほぼ同じですが、基盤としては別々のAWSアカウントで運営されています。このうち日本国外向け環境では、Kubernetes化がほぼ完了というステータスになっています。目下、スタディサプリも移行中です。 Kubernetes化以前は、Deis(Herokuクローン的なもの)
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。 いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。 TokyoGirls.rb Meetup vol.1 https://techplay.jp/event/716251
The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
メンテナンス作業手順の書き方
この記事は「ex-KAYAC Advent Calendar 2018」の11日目の記事です(遅れてすみません 🙇)。 カヤックでの私について⌗ソーシャルゲームのバックエンドエンジニアとして 3 ヵ月、クライアントワークのバックエンドエンジニアとして9 ヵ月の経験を積んだ後、Web のインフラエンジニア(以降、インフラエンジニア)として 4年半従事しました(2018年12月現在、中途採用ページを見るとインフラエンジニアになっていましたが、現在は SRE になっているはずです)。 主にソーシャルゲームの担当で、社内評価システムの実装・運用・保守や Redmine を定期的にアップグレードしたりもしていました。 もともとインフラエンジニア志望だったのですが、私が新卒入社したころはインフラの上で動くアプリケーションのこともわからないといけないということで、まずはバックエンドのエンジニアとして経
2022年6月に、Androidテックリードになった いわたん です。最近、某モンスターを育てたり図鑑を埋めたりするゲームで社内大会をやったらフルボッコにされて涙目でした。悔しくて最近は不思議な力でクラフトしたり空飛んだりして王国を救うゲームやってます。 今回はAndroidテックリードとして1年間やってみた施策の紹介と、それぞれの成果や反省点を紹介したいと思います。これからテックリードになろうとしている方やテックリードをしている方の参考になったり、こんな施策もいいよというアドバイスをもらえたら幸いです。 ZOZOのテックリードの役割と責任 実施した施策 テックリード1on1 読書会 歴史的経緯があるアプリのアーキテクチャ整理へのアプローチ ネーミングセンスを鍛える会の取り組み 案件への関わり方 横断的なコードレビュー 横断的に使う機能の実装 まとめ 最後に ZOZOのテックリードの役割と
SREを実践するための手引きとなる書籍「Site Reliability Engineering Workbook」をGoogleが無料公開、8月23日まで
SREを実践するための手引きとなる書籍「Site Reliability Engineering Workbook」をGoogleが無料公開、8月23日まで 「Site Reliability Engineering」（SRE）は、積極的にコードを書きソフトウェアをおもなツールとすることで高い信頼性を備え十分な性能を発揮するインフラを実現するという、Googleが提唱している方法論です。 GoogleはこのSREを普及させるためのWebサイトを公開しており、そこでSREの教科書的な存在であるオライリーの書籍「Site Reiability Engineering」を、今年の1月から無料公開しています。 参考： Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ GoogleはこのSREの
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
書評: Site Reliability Engineering
SpinnakerによるContinuous Delivery | メルカリエンジニアリング
なぜ使われないダッシュボードが作られるかという話 - satoshihirose.log
監視の考え方 〜あるいは可観測性とはなんなのか〜 - estie inside blog
Retty の Terraform CI/CD 解体新書 - Retty Tech Blog
独りよがりのプラットフォーム / For Whom that Platform Runs
LINEのMySQL運用について 修正版
【SRE Next 2020】発表資料まとめ - Qiita
Microservices時代の監視設計 - An Epicurean
Google - Site Reliability Engineering
Web サービスの信頼性と運用の自動化について / iot40-rrreeeyyy
SmartNewsのサーバーサイドのすべて 大規模サービスを支えるアーキテクチャと技術スタック
SREはインフラエンジニアだけでなく、みんなの活動 - ytake blog
インフラエンジニアのいない会社で働いて 1 年半 - Diary
システム障害との向き合い方 @sinamon129 #tokyogirlsrb
SRE Classroom: The Art of SLOs - Google
テックリードがどんな活動したらよいのか考えて行動してみた話 - ZOZO TECH BLOG
オブザーバビリティ入門