何[復刻版]はSREはAではありません

何SREではありません

HTTPS：// zhuanlan.zhihu.com/p/20695070

 

SRE、サイト信頼性工学の頭字語。これでサイトはウェブサイトを参照して、ウェブサイトは、信頼性工学として翻訳することができます。仕事のこのタイプは、Googleが10年前に作成された、彼らはただで SREの話本から 、以下「SRE」と呼ばれます。したがって、サイトの信頼性エンジニアと呼ばれる仕事をする人-サイトの信頼性技術者は、また、SREを省略。アナロジー：ソフトウェア工学ソフトウェア工学、ソフトウェアエンジニアソフトウェアエンジニア、略しSWE。例：SREは、今SWEに置き換えグーグルでの私の最初の2年間。

最後にSREをやっています

これは、基本的にはSREの人々は、3つの2は私がこの記事を読んだ後、あなたが大まかなアイデアを持っているだけでなく、誤解のいくつかを排除することを願って、知らない、質問をします、すべての候補私の就職の面接です。SREは比較的新しいポジション、いくつかの部門は主にSRE SREの背後にあるグーグルを残すなどグーグル、FacebookやTwitter、Dropboxは、ユーバー、など、この位置（ポジション）を持っている業界をリードするインターネット企業、ごく少数であります作成に関与。（分析：SRE前の2つの文何の頭文字です？）

Googleの現場ではSREの仕事の説明、参考のためにここに記載されている2本に見つけることができます：

• https：//でWWW。google.com/about/career S /＃を検索！トン=ジョー＆JID = 84745001＆
• https：//でWWW。google.com/about/career S /＃を検索！トン=ジョー＆JID = 86645001＆

読者の便宜のために、私はスクリーンショットを置きます：

UsenixのSREは、これまでに3回の会合（SREcon）を開催している、あなたは会議のウェブサイトから特定の議題を見つけることができます。

• SREcon14プログラム| USENIX
• SREcon15プログラム
• SREcon16プログラム

私は、これらの材料は上記読み、私はまだ何をすべきか、具体的SREを理解していないと推定しています。新しい物事の顔には、人々は古いアナロジーを使用するために使用され、物事という「ああ、SREは、名前のものからXXXにグーグルをした。」トマト、ピーマン、玉ねぎ、これらの名前のようにそのように、どのくらいのトマトとナスの違い私が話すことはありません。

SRE特定の作業内容

それはソフトウェア開発者になると、人々の心は、ほとんどの作業の具体的な内容を知っているというようにブラッシング、修理のバグ、コーディング、デバッグ、テストを反映することができるようになります。それSREそれ？

SRE主なタスクは、SLAを確保することです。SLAは、サービスレベル契約の頭字語であり、中国語の翻訳は、我々は略語の良いを使用し続け、適切ではありません。一般に、システムの可用性（dostępność）99.99％を言う、SLAインジケータシステムの機能を指す。要求の95％は、応答遅延（レイテンシ）が200ミリ秒未満である、など。"SRE" 第4章具体的にSLA、SLO、SLIの意味と用法。

私個人的に入れSRE作業は、次のエリアに分かれています。

• キャパシティプランニングと実装

要回答两个基本问题：要支持每秒 X 个请求的流量，需要多少台机器？给你 Y 台机器，如何部署服务栈（serving stack）使其服务容量（capacity）最大，即每秒支持的请求数最多。serving stack 由很多服务程序（server）构成，各个 server 有各自的资源需求（每个进程用多少内存，多少CPU）。每个 server 有多个 replica，我们要算出各个 server 的 replica 的合理数目，让计算资源得到充分利用。SRE 开发了专门的工具来做这件事件，因为我们不想对全球多个数据中心都分别手算一遍。 server 的性能会随时间变化（新版本通常会变慢，因为加了更多的功能），我们要及时调整 replica 的数目。每个 server 的性能变化不一样，replica 的数目要“配平”。

• 部署新的服务集群（serving cluster）

每年都有新的数据中心（Data Center）上线，也有旧的数据中心下线，那么我们的 serving stack 也会跟着迁移。“部署”不是去机房安装机器，实际上工作这么多年，我一次也没有见过跑我写的服务程序的机器。新的数据中心通常会有新一代的硬件，我们的容量规划工具要能适应多种的硬件类型（CPU 数目、内存大小）。

• 冗余与容错

在 Google，我们有数据中心级别的容错，任何一个数据中心可以随时下线维护，对外服务不受影响。进一步说，我们的容量规划要做到允许两个数据中心同时下线。比方说某个数据中心正在例行下线维护，这时另外一个数据中心受突发事件影响必须立刻下线，那么我们的系统还要能正常提供服务。

• 负载均衡

《SRE》第 19、20 章。

• 上线新的服务（on-boarding service）

《SRE》第 32 章。

• 监控（Monitoring）

不是一天到晚盯着 dashboard 看，而是编写合适的监控与报警规则，让我们能快速找到故障根源。几个最基本的监控指标：

1. 流量 traffic, eg. queries per second
2. 延迟 latency
3. 错误率 error ratio
4. 资源使用率 utilization

见《SRE》第 6 章。

• 值班（on-call）

这其实是最少的工作，如果一个 SRE 团队有 8 个人，每人每次值班一周，那么平均 2 个月才轮到一次，占 1/8 的工作量。值班的时候，如果没有突发事件，还是该干嘛干嘛。而且 Google SRE 是全球团队，不用值夜班，到了下午把工作交接给地球另一边的同事就行了。见《SRE》第 11 章。

• 救火（Firefighting）

这是 SRE 最刺激的工作内容，见《SRE》第 12~15 章。

SRE 不是什么

SRE 不在数据中心上班，不搬机器。

SRE 不是系统管理员，不会帮你重置用户密码，也不安装操作系统或升级安全补丁。

SRE 不是测试工程师，不管持续集成和发布新版本。

SRE 不是运维，不过我其实不了解国内的运维具体是做什么的。

会继续补充本文内容……