SRE NEXT 2022 2022-05-15 14:15〜15:00 Track A 非ITの事業会社にSREと言わずにSREを持ち込んだ #srenext
![非ITの事業会社にSREと言わずにSREを持ち込んだ](https://cdn-ak-scissors.b.st-hatena.com/image/square/5d3d94777eda428960d903ec53844741e3ff417c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4bf93f19fbc746c4801ec9188d13ed8f%2Fslide_0.jpg%3F21045710)
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた.これはインフラの権限管理やインフラの構築そのものの指針となる概念であり,自分がそうあるべきだとずっと思ってきた考え方でもある.これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく. Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている. The SRE organization at Google is working to build upon the concept of least
個人的に大切にしていることを書いていきます。少しSREの話が出てきますが、私がSREチームだから出しているだけで、基本的にSREに関係の無い分野でも使えるはずです。 前提となる心がけまず前提となる心がけについて書きます。 エンジニアは恐いと思われている人は自分と関わりの少ない人のことを恐いと思いがちです。 システムはほとんどの人にとってブラックボックスです。そしてシステムを担当しているエンジニアのことも、ほとんどの人にとって未知の存在です。関わりが少ないからこそ、ほとんどの人にとってエンジニアは恐い存在です。 ビジネスをやっていく上で、エンジニアとのやりとりは非常に重要です。そのエンジニアと他の社員のやりとりがしにくい状況だとお互いにストレスが溜まり、不健全な組織となっていきます。 これを解消する一つの手として、例えばチャンネル名が z- から始まるチャンネルは雑談していいというようなルー
Kaizen PlatformでSRE Group Managerをしている前田 (@glidenote)です。4月ということで転職や部署異動など新しい環境で働いている人が多そうなので、今回はKaizen PlatformのEngineering GroupとSRE Groupが行っているOnboardingプロセスを紹介したいと思います。 TL;DR Kaizen Platformに入社してくれた人に最速でPerformanceを出してもらうためにOnboardingプロセスを策定し、運用、日々改善している 入社してくれた人が自身のOnboarding Planを自分で作成し、CTO、メンターとで定期的に期待値の調整、振り返りを実施し、齟齬が発生しないようにする ランチスケジュールを組み毎日別々の人と、別々の場所にランチに行き、一緒に働く人たちとオフィス周辺の情報を知ってもらう 入社した
インフラチームからSREへ 〜メルカリを支える新しいインフラのあり方 Developers Summit 2018/2/16
10 open-source Kubernetes tools for highly effective SRE and Ops Teams If you are running workloads in Kubernetes, your site reliability engineering (SRE) and operations (Ops) teams need right kind of tooling to ensure the high-reliability of the Kubernetes cluster and workloads running in it. Here we present a list of 10 open-source Kubernetes tools to make your SRE and Ops teams more effective t
SREの現場はどうなっているのか――従来型の運用との決定的な違いとは:特集:情シスに求められる「SRE」という新たな役割(3)(1/2 ページ) Site Reliability Engineering(以下、SRE)の現場はどうなっているのか。SREの日常的な仕事とはどのようなものなのか。開発エンジニアと運用担当エンジニアは、実際どのように役割分担し、協力し合っているのか。「SRE本」の監訳者などが語った。 Site Reliability Engineering(以下、SRE)の現場はどうなっているのか。SREの日常的な仕事とはどのようなものなのか。開発エンジニアと運用担当エンジニアは、実際どのように役割分担し、協力し合っているのか。 2017年9月25日に、書籍『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム(以下、SRE本)』の
NewRelic / Elasticsearch ではじめるSREに必要な性能監視入門 https://supporterzcolab.com/event/177/ にて話した資料です!
2016/9/12 OSS運用管理勉強会主催セミナー クラウド時代のIT運用管理 ~OSSツールは商用ツールに追いついたか?~Read less
セクションナイン の 吉田真吾(@yoshidashingo)です。 SRE本の原書が出てから早1年半が経ちました。原書はすでにオンラインで無料で読めるようになっています。 Google - Site Reliability Engineering 前回このブログでSREについて書いたのが、原書の出る1ヶ月くらい前ですね。 yoshidashingo.hatenablog.com 国内でもSRE部署の設置が急速に進んでますが、運用部門をSREと看板を掛け替えただけの劣化コピーが大量生産されていることも否めなかったりなかったり。 そもそもSREは、従来のシスアドではなくソフトウェアエンジニアです。そして、開発/運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すための組織設計であり、そのための技術ノウハウです。 今日は今週末発売さ
ここから、DevとOpsが協力すればより効率的になる=DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか? ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート(設置作業員、サポートセンタ)には、大量の人員が必要になってきます。 したがって、組織を研究
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く