タグ

SREに関するjinjin252525のブックマーク (70)

  • SLO のエスカレーション ポリシー : CRE が現場で学んだこと | Google Cloud 公式ブログ

    前回のブログ記事では、信頼性と機能開発の間で生じる技術的な苦労や、サービス レベル目標(SLO)が満たされていないサービスに対して、企業はいつどうやってエンジニアの時間を信頼性向上に費やすよう決断すべきかについてお話ししました。今回は、SLO のエスカレーション ポリシー(一部編集済み)と、それに関連する Google の SRE チームによる論理的根拠を解説し、開発速度の迅速さを保つために SRE と開発の各チームがどこに妥協点を置いているのかを紹介します。 この SRE チームでは、サービス スタックのさまざまな領域に注力する大規模な開発チームと連携しています。そのスタックには、トラフィックの多いサービスが約 10 件、比較的小規模なサービスが 10 数件含まれており、すべて SRE チームがサポートしています。チームは欧州と米国に分かれており、それぞれの地域で日中オンコール担当となる

    SLO のエスカレーション ポリシー : CRE が現場で学んだこと | Google Cloud 公式ブログ
  • SRE部が発足しました - Chatwork Creator's Note

    こんにちは。インフラマネジメント部 改め、SRE部のid:cw-tomita です。1月の組織変更で部署名の変更が行われました。せっかくの機会ですのでCreator's Noteで紹介したいと思います。 SRE(site reliability engineering)という言葉自体はエンジニアの方であれば結構知られているかと思いますし、また、様々な会社で既にSRE部/チームが発足していて、たくさんの紹介記事もありますので、"SREとは"みたいな所は以下のブログなどを参考にしていただければと思います。 インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog SRE チームを設立します - Cybozu Inside Out | サイボウズエンジニアのブログ さて、SRE*1 や↑の

    SRE部が発足しました - Chatwork Creator's Note
  • SREサイトリライアビリティエンジニアリングを読もう - yoshidashingo

    セクションナイン の 吉田真吾(@yoshidashingo)です。 SREの原書が出てから早1年半が経ちました。原書はすでにオンラインで無料で読めるようになっています。 Google - Site Reliability Engineering 前回このブログでSREについて書いたのが、原書の出る1ヶ月くらい前ですね。 yoshidashingo.hatenablog.com 国内でもSRE部署の設置が急速に進んでますが、運用部門をSREと看板を掛け替えただけの劣化コピーが大量生産されていることも否めなかったりなかったり。 そもそもSREは、従来のシスアドではなくソフトウェアエンジニアです。そして、開発/運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すための組織設計であり、そのための技術ノウハウです。 今日は今週末発売さ

    SREサイトリライアビリティエンジニアリングを読もう - yoshidashingo
  • 運用自動化も障害対応も、全ては「現場のため」ではなく「顧客のため、ビジネスのため」

    運用自動化も障害対応も、全ては「現場のため」ではなく「顧客のため、ビジネスのため」:特集:情シスに求められる「SRE」という新たな役割(1) デジタルビジネスの激化を受けて、「いかにスピーディにITサービスを企画・開発するか」が重視されている。だが重要なのは「作ること」だけではない。リリースして以降、収益・ブランド向上はサービス運用を支える「運用管理の在り方」に掛かっている。特集では米グーグルが提唱するSRE――Site Reliability Engineerの概念を通じて「運用管理のビジネス価値」を再考。今求められる情シスの役割を考える。 ITサービスは「作った後」こそ重要 IoT、X-Techトレンドの高まりに象徴されるように、国内でも「テクノロジの力で新たな価値を生み出す」デジタルトランスフォーメーションが進んでいる。もはやUberなどの例を持ち出すまでもなく、“これまでになかっ

    運用自動化も障害対応も、全ては「現場のため」ではなく「顧客のため、ビジネスのため」
  • 可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと | Google Cloud 公式ブログ

    この『CRE が現場で学んだこと』シリーズでは前回、ロード シェディングという手法で「成功による障害」を切り抜ける方法について紹介しました。これに対して素晴らしいフィードバックをたくさんいただきましたが、その中に、いかにして数値を事業目標と結びつけるべきかという質問がいくつかありました。 そこで今回は、最初の原理に立ち戻り、そもそも成功とは何を意味するのかを追究し、実際にシステムが成功しているかどうかを把握する方法について考えてみたいと思います。 成功の前提となるのは可用性です。可用性のないシステムは機能を実行できませんし、最初の段階で失敗します。では、可用性とは一体何なのでしょうか。まずはこの言葉を定義しなくてはなりません。 可用性とは、システムが意図した機能をある時点で実行できるかどうかということです。可用性の測定はレポーティング ツールとして活用されるほか、過去の可用性を見ることで、

    可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと | Google Cloud 公式ブログ
  • SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud 公式ブログ

    前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標(SLO)と呼びます。 今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。 SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標(SLI)といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所に

    SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud 公式ブログ
  • 闇のDevOps DevOpsと業績評価 – ところてん – Medium

    ここから、DevとOpsが協力すればより効率的になる=DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか? ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート(設置作業員、サポートセンタ)には、大量の人員が必要になってきます。 したがって、組織を研究

    闇のDevOps DevOpsと業績評価 – ところてん – Medium
  • Googleのインフラ技術から考える理想のDevOps

    デブサミ2017で発表予定の資料です。 http://event.shoeisha.jp/devsumi/20170216 2017/02/14 ver1.0 公開

    Googleのインフラ技術から考える理想のDevOps
  • 次世代監視の大本命! Prometheus を実運用してみた - Qiita

    こんにちは!freeeでインフラゾンビをやっている @sugitak です。ゲームではレベルを上げて物理で殴る派です。 freee ではたまにインフラエンジニアの数が減るのですが、その減ったインフラエンジニアはインフラゾンビへと進化し、社内を闊歩します。インフラゾンビは主に開発チームに所属して、アプリっぽいインフラの仕事をインフラからアプリ側へと持っていきます。デプロイとか、Dockerとか、Jenkinsとかの、いわゆる DevOps 系のところですね。こうすることで開発者は手を出せるものの自由度が増えるし、インフラはより来のインフラとして純度を上げていける、 so, win-win ってわけです。 さて、そんなわけで監視です。freee Engineers Advent Calendar 2016の9日目の記事として、 Prometheus による監視が最高なのでみんなもっと使おうと

    次世代監視の大本命! Prometheus を実運用してみた - Qiita
  • インフラチーム改め Site Reliability Engineering (SRE) チームになりました

    インフラチーム改め Site Reliability Engineering (SRE) チームになりました Organization Author: kazeburo インフラチーム改めSite Reliability Engineering チームの @kazeburo です。この記事ではまだ馴染みの薄い Site Reliability Engineer とは何かについて紹介したいと思います。 SREとGoogleのSRE Site Reliability Engineerは日語にすると「サイト信頼性エンジニア」となりますが、あまりキャッチーではないので普段は略語の「SRE」を使用しています。SREという職種は日ではあまり聞く事はありませんが、FacebookやAirbnb、Dropboxなどの企業でSREが募集され、それぞれのサービスを支える重要な役割を担っていると思われます。

    インフラチーム改め Site Reliability Engineering (SRE) チームになりました