SREはトイルの削減にどう立ち向かうべきか? - Qiita
はじめに Googleが提唱するSREプラクティスの一つにトイルの削減 1 があります。トイル (toil) という言葉は日本語であまりなじみがありませんが、「苦労する・こつこつ働く」といった意味合いがあります。 SREにおけるトイルの定義は、原典とも言える書籍 SRE サイトリライアビリティエンジニアリング 内で次のように定義されています。 トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。 本記事では、システム運用におけるトイルの定義を再確認し、トイルを削減する上での実践的なノウハウの一例を紹介します。 トイルの定義 SRE サイトリライアビリティエンジニアリング では、次の分類に1つ以上当てはまるような業務はトイルとなる性質が
『家族アルバム みてね』を支えるオンコールエンジニア制度 | gihyo.jp
株式会社MIXIで『家族アルバム みてね』（以下みてね）のSREグループに所属している本間です。 みてねは現在、1,500万人を超えるユーザに175の国と地域でサービスを提供しています(2022年8月現在)。そこで、より高い信頼性と可用性を担保するためにみてねのSREグループではオンコールエンジニア制度を設けています。 今回はこの「みてねのSREグループにおけるオンコールエンジニア制度の取り組み」についてご紹介させて頂きます。 オンコールの定義 まず、どのような条件でアラートを設定しオンコールを実施するかの定義について簡単に触れておきます。 現在はさまざまなソースから多種多様な情報を収集することができます。 たとえば、みてねではKubernetes（Amazon EKS）を採用しています。Kubernetesだけでも非常に多くのメトリクスが収集できますが、それだけではなくアプリケーション
SRE Gaps#2「SREの実践」 スタートアップカオスとSRE
https://forkwell.connpass.com/event/253146/
GMOペパボでのSREの実践 / SRE Practices of GMO Pepabo, Inc.
2022/07/26 に実施された "SRE Gaps#2「SREの実践」" https://forkwell.connpass.com/event/253146/ 登壇時の資料です。
SRE に成る君に最低限の開発力を身に着けてほしい - じゃあ、おうちで学べる
はじめに まず、はじめに皆さんへ言っておきたいことがあります。 このドキュメントの目的は皆さんをやる気にさせて一心不乱にコードを書きまくって新機能追加や改善をしてソフトウェアを開発していってほしいというわけではないということです。 もちろん、そうなってくれれば嬉しいですが気合が入ったからプログラムを急に書けるようになるわけではないのでそのような目的は一切ありません。また、この文章にはインフラエンジニアがコードを読み書きできなくて良いという意図はなくポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。 SREはそもそも、コードを書かなくてもよいエンジニアではない SREとは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームや役割を指します。 Google では、SREチームの50～
AWSコスト倍になっちゃった！〜削減への道のり〜 - freee Developers Hub
こんにちは、DevBrandingのellyです。5月20日に配信した「AWSコスト倍になっちゃった！〜削減への道のり〜」の様子をご紹介します。 今回はITストラテジーチームとSREチームから2人のゲストを招いて、freeeで実際に起きたAWSコスト増加の事例をもとに、気がつけば増えるインフラ費用の無駄をどのように見つけ、コスト削減していったのか、実話のストーリーを話してもらいました。 登壇者集合写真 miry:写真左上。2015年入社。ITストラテジー。全社のITツールのコスト管理やIT戦略の策定を担当。 nakagawa:写真右上。2020年5月入社。SREチームエンジニア。基盤の更改やクラスタ管理効率化を担当。 のぶじゃす (@noblejasper): 写真右下。ラジオパーソナリティ、2017年に中途入社。mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee
SRE NEXTで「AIOps研究録」講演を終えて - ゆううきブログ
5月14-15日に開催されたSREの国内カンファレンス SRE NEXT 2022 ONLINEにて、「AIOps研究録―SREのためのシステム障害の自動原因診断」と題して、ITシステムに障害が発生した際に、機械学習・統計解析の手法を用いて、障害の原因を自動で診断するための研究について講演しました。 講演に用いたスライド資料を以下に公開しています。 当日に配信された講演動画は、Youtubeに公開されています。 なお、この記事では、AIOpsという用語を、機械学習や統計解析をはじめとするAI（人工知能）と呼ばれる技術を用いて、ITオペレーターのオペレーション作業を自動化あるいは支援する技術の総称として使っています。 なぜAIOpsに着目したのか 自分が、統計や機械学習をはじめとするAIと呼ばれる技術をSRE分野に適用することを漠然と考えはじめたのは、2017年ごろでした。当時、今後のSRE
SRE NEXT 2022で「プロダクション環境の信頼性を損ねず観測する技術」というお話をしました - ださろぐ@はてな
登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運
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エンジニアは何故混同されるのか - Qiita
Introduction タイトルの内容について、定期的に良く周りから聞かれるので、私個人の見解で書いてみました。 あくまで個人の意見(※)ですが、何か参考になれば幸いです。 ※筆者は元SIerでAWS Solution Architectをやっており、1年前にWeb系に転職して、SREエンジニアに鞄替えした人間でして、お世話になっている各種SREの勉強会や日々の業務から学んだ内容に基づいた見解となります。 インフラエンジニアとSREエンジニアは何故混同されるのか 混同されがちなのは、現状のムーブメントでは、技術スタックや業務内容の多くが被っているからだと思ってます。特にインフラエンジニアの中でも、クラウドエンジニアの分類の方たちと多くが類似しているからだと感じてます。 改めて、SRE(Site Reliability Engineering)とは、DevOpsの思想を実践する為のプラクテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
トレンドマイクロのSRE組織・業務のご紹介 - Qiita
SRENEXT2022 組織にSREを実装していくまでの道のり
SRE NEXT 2022 ONLINEの発表資料まとめ - Qiita