我开始从事SRE业务了。

我已经转职成为一名SRE工程师并开始工作了。
在转职后，由于完全不知道该做些什么，我在向前辈请教的过程中觉得有必要记录下一个大致的概述，所以我会持续进行记录。
此外，我计划随时更新这篇文章。

在构建系统时需要始终意识到的事项

在考虑系统时，我认为以下三点是重要的。

可伸缩性 (kě kuò

即使负荷增加，也可以保持性能的功能称之为负载均衡。
当大量的流量到来时，服务器会过载。
而如果服务器能够自动增加服务器，就能够防止因流量而导致的系统故障。

Kubernetes是可以轻松实现此设置的工具。
例如，Kubernetes有两种扩展方法：水平扩展和垂直扩展。
可以进行的扩展包括Pod和Node。下面的文章对Kubernetes中的Pod和Node的自动扩展提供了参考。
关于Kubernetes的Pod和Node的自动缩放。

多余的长度

這是確保系統可靠性的特性。
主要是關於數據庫的討論。

数据库的布局

假设以AWS Aurora为例，我认为首先需要考虑安排多少个Read Replica以及如何设置它们。常见的做法是根据不同的区域设置Read Replica（在多可用区中设置）。同时，还需要考虑到S3等地方可以适用此冗余性，需要考虑这一点。

备份

每天进行备份的话，基本上没有问题。

举个例子，如果使用AWS Aurora，它会自动进行备份。

AWS Aurora每天保存快照，并且可以从快照中进行恢复。

在考虑冗长性时变得重要的问题是什么？

• サーバー1台死ぬ可能性はあるか

 

• マルチリージョンにしてて、一つのリージョンが死ぬ可能性はあるか

 

• 　以前のAWSの障害の場合どうするか？⇛年間0.1%が発生可能性

 

• Masterが詰まって機能しなくなるケースはどうする

 

• データが失われて、バックアップを使用しなくてはいけない可能性はどのくらいあるか

 

どのくらい過去にさかのぼってデータ復旧をしなければいけないか

维护性

这里包含着两个意思。

简单性

对于新开发成员来说，如何留下友好的信息

我认为最好的方法是定期留下文档等资料，只需查看图表和文件即可进行追赶。

2. 学习成本的降低
指的是即使对于新工程师来说也容易理解且学习成本较低的基础设施架构。

应用性

让其他成员更容易操作！！

容器基础设施建设.

我想用基于Kubernetes的方式来写。

Kubernetes 参考文献

我认为理解如何构建容器基础设施是很重要的，这里我将介绍与Kubernetes相关的一些重要文章。
待办事项：更新参考文章
Kubernetes: 调度器的运作

集群的组成

我认为主要有两种类型。

区域集群

区域集群

使用默认设置创建时，将在一个区域内的一个区域中创建一个集群。

多区域集群

在一个区域内创建一个独立的集群主节点，并在多个区域内创建节点的方法非常简单，只需将区域分开即可进行轻松构建。

区域聚类

在3个区域创建3个集群主节点的方法。
默认情况下，在3个区域创建节点。
对于小型服务来说，可能会创建太多的节点。

尝试使用GKE的区域集群（Beta版）

需要将节点设置为多少个？

我认为这是首先要解决的问题。
基于etcd的Raft算法的特性，建议使用3、5、7等奇数个节点。
请查看下面的详细信息。

为什么需要至少三个节点?

以下是有用的参考资料：
https://qiita.com/ntoreg/items/ec6f1eca87ba5c5c0399
https://www.techscore.com/blog/2019/03/28/raft-consensus-algorithm/

应该将 ReplicaSet 设置为多少个？

确定应保持多少个Pod是一个决策事项。
可以通过以下方程式来计算数量，但需要在实际运营或负载测试后决定。

需要的复制品数量 = ceil(sum(当前Pod的CPU使用率) / 目标平均利用率)

参考本：Kubernetes全面指南

構建CI/CD管道

观点

• 自動化

人の手を介入させない

高速化

デプロイは速いほうがよい。ビルドとか時間かかるのは嫌

属人性の排除

誰でもデプロイできる

最初的部署自动化中，没有考虑到高级部署方法（如绿色部署）。
原因是考虑到后续可以进行替换，并且高级部署方法需要付出学习成本。
但是我认为只需假设以后能够采用即可。

Kubernetes 部署方法

这一次，我希望把重点放在使用Kubernetes进行部署的方法上。

在CirrcleCI上进行部署

感觉使用这个公司的人最多。
如果能进行CI并从中进行部署，那就太好了。

旗帜

Spinnaker 新式帆等启动机

NetFlix正在开发并适用于高级部署。
高级部署是指部署到多云端、金丝雀部署以及蓝绿部署等部署方法。
然而，学习成本常被视为其中的一个缺点。

PLAID工程师博客主页PLAID招聘工程师中！PLOG Netflix的SRE在”Spinnaker”开源软件中的多云部署讲述 #builderscon最近关于部署方法的总结。

Skaffold = 脚手架 jià)

Skaffold 即为一种选项。

优点
·由Google制作，值得信赖
·似乎有自动给图像添加标签的功能

缺点
・听说构建速度慢….
・需要在本地设置kubernetes配置
・需要了解kubernetes知识

如果你在Kubernetes的开发环境上遇到困难，可以使用Skaffold。
Google开源了一个面向开发者的Kubernetes命令行工具Skaffold。

GitOps 是一种采用 Git 作为操作集中管理工具的运维方法。

我们将以Github的源代码为准，并围绕Github进行持续集成和持续交付，这是一种思路。

优势：
– 看起来易于引入
– 似乎很流行

缺点：
如果Github宕机，将无法完成任何工作。

用什么？

实现GitOps的工具正在不断增加。
ArgoCD、Flux等是非常有名的。

使用Cloud Build实现GitOps风格的持续交付
通过Argo CD在GKE上实现GitOps

在部署方面的考虑

• masterにマージする前に、デプロイしたい場合があること

 

• PRをマージすることでデプロイすることが正解ではない

 

• Circle CIを使うのが正解ではない

 

• Githubが落ちた時にきちんとワークするか、デプロイできるか

 

• 手動をあえて残す方法を検討すべきか

 

• マージはしたいけど、deployしたくない場合どうするか

 

ブランチ単位のdeployしたいときどうする

监视

监视中的重要事项。

1. 以怎样的细粒度发出警报为宜？

 

1. 为了避免警报疲劳，需要以适当的粒度管理警报。

 

1. 对于Kubernetes的监控，经常会有这两个问题。

 

1. 应该监控哪些地方？

 

从发出警报后如何追踪到原因的步骤是怎样的？

在哪里进行监视和监控什么

暂时结束任何活动？

据入门监控所述，HTTP响应代码和请求时间（延迟）似乎是有效的。

你在哪里

与用户最近的地方。适用于CloudFront等（较初级的监视）。

数据收集

有关正在收集哪些数据以进行监视的讨论。
主要有两个部分。

度量

每60秒获取一次指标是推荐的频率（来自入门监控）。

日志

举例来说，如果使用GCP，日志会被记录在Stack Driver中；而如果使用AWS，日志会记录在S3或CloudWatch中。

“Slack通知” 可以被改写为： “Slack消息”。

重要的错误发生时将通过Slack通知。
首先要检测到错误非常重要。
然后需要注意的是警报的粒度。
如果警报太多，人们会渐渐不去关注，但如果警报太少而不能通知重要事项也会有麻烦。所以我们需要设计出能够持续引起成员关注的频道。
这方面我们目前正在试验和摸索中。

停机时间

我們正在尋找即使系統崩潰也無妨的時間。但是，由於我們是初次提供服務且團隊規模較小，可能會忽略崩潰並超過預定時間的可能性較高。因此，我認為比設定停機時間更重要的是設計如何發出警報。

下面是可以参考的文章，用于决定可以接受的停机时间。
等一下！在使用Aurora时，真的需要Multi-AZ吗？

在这篇文章中，首先我们会提出“是否可以容忍（服务等中断停止的时间）长达10分钟？”的问题，并决定如何设计冗余性。
※考虑到本次重点在于“警报的设计”，因此将其列入监控事项。

只要实际停机时间为10分钟，这个问题意味着这家公司拥有夜班团队，或者有能力建立夜班团队。

监视工具

让我们来看一下Kubernetes监控工具。

推送型和拉取型

关于Push型和Pull型监控系统，时代的潮流是从Pull型转向Push型？

数据狗

关于Datadog的综述内容很好
针对监控系统的推送和拉取方式以及对Prometheus的思考

优点：
– CloudWatch和GKE的集成很容易。可以通过简单的设置将AWS CloudWatch信息、其他监控工具（如NewRelic）的信息等导入到Datadog中。通过使用这个功能，可以将仪表盘信息统一到Datadog中。
– 配置（包括安装）很容易，可以通过图形用户界面进行操作。
– 遵循时代潮流，因为是推送模式，所以更想使用这个…
– 用户界面很漂亮…

缺点
・需要花费金钱⇛最低每月约10000日元左右
・当监控对象增加时，监控服务器容易集中负载
⇛目前服务器数量不多，因此在缺点方面较为弱
・若今后需要监控APM（应用性能监控），费用将翻倍。

普罗米修斯

优点
・免费

缺点：
·与Datadog相比，设置（安装等）比较麻烦。
·目前不清楚如何集成Cloud Watch和GKE。
·当使用AutoScaling等功能使监视对象的数量发生变化时，需要手动更新监视对象列表。这一点相对麻烦。

关于监控系统的推送型和拉取型方法以及对Prometheus的思考
再次介绍云时代的监控工具Datadog
【运维监控工具比较】我们已经开始从ZABBIX迁移到Prometheus

高度可移动的集装箱设计

使用docker-compose命令只需一步即可建立开发环境，并能够管理迁移和种子数据，如果需要获取分阶段环境或生产环境的镜像，可以立即获得，这种状态被认为是最佳的。
用更难的话来说，就是”immutable且disposable”，即不可变且可丢弃的。

不可变基础设施将改变应用程序的架构。

基础设施的代码化

为什么应该区分IaC和CaC？

只有这种方法在应用上更方便，如果统一考虑，将不得不执行从代码到基础架构建设的过程。

为什么要进行IaS（基础设施即代码）呢？

作为基本思路，有以下两点：
– 为了将云基础设施的创建方式以代码方式保存下来。
– 为了能够通过执行同一环境下terraform命令即可立即创建。

基础设施即代码 (IaC)

建構伺服器

主要使用的工具

• Terraform

 

Cloud Formation

配置即代码 (CaC)

请注意，为了便于叙述，下面的答案将输入的内容中的一些文字进行了适当的调整。

安装各种工具和库
① 使用Terraform进行文件夹管理
使用Terraform进行管理，会有可能错误地执行建立文件夹的操作？
② 使用其他工具执行
Puppet、Chef、Salt、Ansible
考虑到学习成本，使用Ansible可能更合适。

基础设施即代码再考
我之前不理解基础设施即代码。
使用Puppet、Chef、Salt、Ansible管理Compute Engine-附录

权限设置

很明显，如果不设置权限，人为错误就容易发生。这种事故最可怕，也是最有可能发生的。
为了从根本上减少这种事故的发生，我认为首先要将适当的权限授予适当的人。

我将随时更新！！！