こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/302c687d38c4c4d147ea654aee7a5a236bb8fb24/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Ff67cec5a98f2cda8a383d7d3db7e4802dfc0a94b%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fh%252Fhatenatech%252F20240319%252F20240319125826.jpg)
インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね？って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ
本日2022年6月21日、Cloudflareの19か所のデータセンターにおいて、トラフィックに影響を与える障害が発生しました。折り悪くこの19か所の拠点は当社最大の拠点であり、全世界のトラフィック処理の大半を占めています。この障害は、当社のインフラの重要な一部であり、Cloudflareのトラフィックの大部分を処理する当社最大の拠点における耐障害性を高めるための長期的なプロジェクトの一環として行われた変更により発生したものです。06:27 UTC、今回の障害の原因となったネットワーク設定の変更をこれらの拠点で実施。06:58 UTC、最初のデータセンターがオンラインになる。07:42 UTC、すべてのデータセンターがオンラインになり、正常稼働となる。 お客様の拠点によっては、Cloudflareを使用するWebサイトやサービスにアクセスできない場合があります。その他の拠点では、Cloud
2023/05/19 「SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会」発表資料 https://findy.connpass.com/event/281605/
Twitter supposedly lost around 80% of its work force. What ever the real number is, there are whole teams with out engineers on it now. Yet, the website goes on and the tweets keep coming. This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I’d like to explain my little corner of Twitter (though it wasn’t so little) and some of
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
We encounter a lot of organizations talking about or attempting to implement SRE as part of our consulting at Real Kinetic. We’ve even discussed and debated ourselves, ad nauseam, how we can apply it at our own product company, Witful. There’s a brief, unassuming section in the SRE book tucked away towards the tail end of chapter 32, “The Evolving SRE Engagement Model.” Between the SLIs and SLOs,
Summary of June 8 outage
Summary of June 8 outageWe experienced a global outage due to an undiscovered software bug that surfaced on June 8 when it was triggered by a valid customer configuration change. We detected the disruption within one minute, then identified and isolated the cause, and disabled the configuration. Within 49 minutes, 95% of our network was operating as normal. This outage was broad and severe, and we
テクノロジーの進化に合わせて、データベースもまた進化しています。従来のパフォーマンス、スケーラビリティが重要なことはもちろん、今日ではセキュリティ、インフラのコード化、CI/CD、クラウド活用といったタスクにも取り組んでいかなければなりません。 データベースの本質は、長期的に安定していること。つまりリライアビリティ（信頼性）です。時代とともにアーキテクチャやツールが変わってもこの原則は変わりません。本書はデータベースのリライアビリティを実現するための考え方を「データベースリライアビリティエンジニアリング」と定義して、その具体的な手法を紹介します。 はじめにDBREの基本概念を解説し、サービスレベルの定義と測定、リスク評価と管理、オペレーションの可視化に進みます。そして、データベースを取り巻くインフラストラクチャの構成管理と自動化、バックアップとリカバリ、リリースマネジメント、セキュリティ、
メルカリSREの@kazです。 今日は、メルカリの所有する物理サーバのセットアップと設定配布の自動化をどのように実現したかをお話します。 メルカリのデータセンタ 本題に入る前に、メルカリが現在構築している自社データセンタ（東京DC）についてご紹介します。 メルカリでは現在、基幹システムのMicroservice化を進めています。各Microservicesの開発においては、そのサービスの特性などを鑑みて、チームの裁量で柔軟にインフラを選択することが可能です。その結果として、メルカリはさくらインターネット、GCP、AWSなど複数のクラウドにまたがって運用される状況となりました。 こうした中、SREチームが問題視したのは「各クラウドデータセンタ間の物理的距離」です。メルカリでは、コストダウン・低災害リスクの観点から、主にさくらインターネットの石狩リージョンを利用しています。一方で、GCPやAW
製品の導入を勧めている中で必ず聞かれるのが、「リソースはどのくらい必要ですか」。キャパシティプランニングなんて言ったりしますが、これ、エンタープライズアプリケーションの中ではかなり重要で、炎上も頻発しやすいテーマです。今日はそんなお話。 タイミングはいつなの？ いわゆるパッケージソフトウェアだと、必要なCPUのスペック、メモリのスペック、ディスクのスペックは大体書かれています。それは機能が固定されていて、変動するところはデータ部分のみになるので、xxGB以上のメモリ、YYGB以上の空き容量 等と、最低限の条件が書けます。ハードウェアを調達するには、使うパッケージに合わせるのが普通かと思います。 ところがです。エンタープライズアプリケーションという分野では、スクラッチで開発するので、どのような機能が付き、どのような画面があり、どのようなデータが来て、どれくらいの処理能力が必要なのか は、見積
(This post is also available in English.) この記事は Linux memory management at scale を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 cgroup2 プロジェクトでの私の仕事の一部として Linux システムのリソース管理についてエンジニアと話すことに多くの時間をかけてきました。 これらの会話を通じてどんどん明らかになってきた 1 つの事実は多くのエンジニアは、シニア SRE たちでさえも、 Linux のメモリ管理についていくつかのよくある誤解を持っていて、そしてそれが彼らがサポートするサービスやシステムが本来確実に稼働したり効率的
総合グループウェア「サイボウズOffice」や業務アプリ構築サービス「kintone」などをクラウドサービスとして提供するサイボウズでは、サービスの運用を自動化するため、コンテナオーケストレーションツールのKubernetesなどを活用したインフラ刷新プロジェクト「Neco」を推進している。 サイボウズではどのようなインフラ刷新を行っているのか、2019年7月22～23日に開かれたCloud Native Days Tokyoでサイボウズの池添明宏氏が講演した内容を要約してお伝えする。 運用負荷が高い状態をどうにかしたい サイボウズでは、社内のデータセンター（DC）にVM（仮想マシン）を構築し、アプリケーションをマルチテナントで運用する仕組みを構築していた。しかし、煩雑な手作業などが発生して、運用負荷が高い状態が続いていたという。 こうした状況を改善するため、2018年1月にインフラ刷新プ
AWS での Apache Kafka の実行のためのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ AWS での Apache Kafka の実行のためのベストプラクティス この記事は Intuit とのパートナーシップに基づいて書かれ、AWS で Apache Kafka クラスタを実行するための学習、ベストプラクティス、推奨事項を共有するものです。Intuit の Vaishak Suresh と同氏の同僚の方々の貢献とサポートに感謝いたします。 Intuit の概要: Intuitは、AWS のエンタープライズ顧客のリーダーであり、ビジネスと財務管理ソリューションのクリエーターです。Intuit の AWS とのパートナーシップに関する詳細については、以前のブログ記事 Real-time Stream Processing Using Apache Spark Streaming and Apache Kafka on AWSを参照し
1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来 Kubernetesの設計思想に共感して、1,000台規模のインフラ刷新プロジェクトに採用したサイボウズが、独自のインフラ、自社開発のOSSツールで挑戦するNoOpsな未来について聞きました。 1,000台規模のインフラをKubernetesで刷新する なぜパブリッククラウドではなく独自インフラなのか インフラ自体を継続的デリバリするためツールをOSSで Kubernetesの設計思想にインスパイアされたNeco ビジネスとして大切にしている部分は細部まで自分たちで 主力製品の「サイボウズ Office」「Garoon」「kintone」などを、2011年からクラウドサービス cybozu.com として提供してきたサイボウズ。これらのサービスのために同社が自前で構築したインフラ基盤は、国
1. LINEのMySQL運用についてKentaro Kitagawa, IT service center - database department - db1 team DB Tech Showcase 2018 2018/09/20 2. 北川 健太郎 / Kentaro Kitagawa LINE株式会社 IT Service Center - Database dept.- DB1 Team データベースエンジニア MySQL / Oracle Database / Redis MySQL道普請: http://gihyo.jp/dev/serial/01/mysql-road-construction-news Introduction @keny_lala
この記事では、自分が数年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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
