业务需求

云上修改任务维护安全任务

什么是系统运维

应用部署

高可用

持续监控运行情况

基础设施本身的监控例如服务器 EC2
应用监控服务存活业务负载

提升系统稳定性和可靠性

例如SRE角色持续的强化

安全性

网络攻击保护业务数据安全

优化成本

五大支柱

在云上部署、架构设计、运维可以从这五个角度进行考虑

安全性可靠性性能效率成本优化卓越运营

通用设计原则

1资源是弹性的即开即用短时间内可以伸缩资源

AWS 基础设施数据中心多方便业务扩展几条命令就可以创建资源

资源可以编程

以前的方式

资源采购
IDC 上线机器

2以生产规模测试系统

测试、开发、生产环境不一致以前测试环境的资源、版本、数据和线上不一样现在按照一样的配置准备服务器，然后copy一样的数据

3 自动化

所有的资源可以通过API进行调用可以重复操作保证环境的一致性以及环境的演化过程

演进式架构

利用数据驱动架构

通过数据分析

哪些业务流程需要优化
线上哪些地方容易出问题
哪些操作频繁需要做自动化

game day 鼓掌演练

模拟数据中心停电的场景生产环境的副本关闭一些服务器看线上服务的运行情况

五大支柱

读一下白皮书 aws.amazon.com/architectur…

设计原则

运营及代码 operation as code
- 所有的运营操作全部代码化
- 每次都按照流程手工操作可能会出现执行错的情况如果做成代码犯错的几率变小
频繁可逆的微小更改
- 例如一周一版更新了20哥功能(一回滚就得都回滚) 云上建议是频繁发布一次一个即使回滚也是影响一个
- 后面会讲到 change management
经常优化运行的程序
- 技术一直在演进代码优化
预见故障(不能全都依赖AWS 自己也想好故障方案)
- 提前想到业务的增长评估是否会对架构有影响提前扩容
- 单点故障也是需要思考
- 提前准本好修复脚本降低影响甚至自动修复
从故障中吸取教训
- 经常遇到的问题虽然会被修复但是也要考虑问题出在什么地方拉产研团队一起分析从根本上修复

最佳实践

准备阶段

优先级

安全和性能的取舍需要确定哪个优先级高然后才能设计产品架构、运维 CMDB 资产打标签标准化 runbook 遇到一个问题找着文档一步一步操作或者执行脚本

运营阶段

了解运营的状况

资产的数量业务量

响应事件

监控、变更
提前做好计划计划内的有runbook 计划外的也要有runbook
要有上升

演进阶段

从经验中学习

卓越运营的关键服务

AWS congfig ---CMDB AWS-x ray---监控 system manager自动化运行工具 lambda 代码修复

问题:

资源伸缩的触发条件? 是人工去点点点还是自动化调用命令？是要自己去编排扩容的操作吗

autoscaling 策略
- 性能 cpu
- 请求
无状态服务

原则: 设计部署运维

IAM

IAM委托人

AWS Identity and Access Management (IAM) 是一种Web 服务,可帮助您安全地控制对AWS 资源的访问权限。使用IAM 控制哪些用户能通过身份验证(登录)并获得授权(拥有权限)来使用资源。将IAM 视为一种工具,用于集中管理启动、配置、管理和终止资源时所用的权限。您可以对访问权限进行精细控制。此控制基于资源并扩展到准确确定允许每项服务的哪些API 调用。

IAM用户

用户名密码
AK SK

联合身份用户

公司内部分很多部门使用AWS外部认证系统然后用对应的身份登录AWS 类似微信登录授权的东西

应用程序

服务访问 AWS服务例如S3 需要授权代码需要授权可以套用AK SK 也可以临时获取ticket

IAM 角色

安全凭证

IAM user用于日常操作

AK SK 使用编程的时候需要使用的

IAM user有
role you

多因子认证

IAM 用户

需要显示的授予权限

IAM 角色

用户可以戴帽子服务也可以戴帽子

临时授权干什么事情就拿对应的帽子(凭证) 会有过期时间 AK SK不要直接写到代码里面

IAM角色是可在账户中创建的一种具有特定权限的IAM 身份。IAM 角色类似于IAM 用户,因为它是一个AWS 身份,该身份拥有的权限策略可确定其在AWS 中可执行和不可执行的操作。但是,角色旨在由需要它的任何人代入,而不是唯一地与某个人员关联。此外,角色没有关联的标准长期凭证,如密码或访问密钥。相反, 当您代入某个角色时,它会为您提供角色会话的临时安全凭证。何时使用 IAM 角色您可以使用角色向通常无法访问您的AWS 资源的用户、应用程序或服务授予访问权限。例如,您可能希望授予您AWS 账户中的用户访问以下内容的权限: • 他们通常没有的资源 • 其他账户中的资源 • 使用AWS 资源的移动应用程序但是,您不想在应用程序中嵌入AWS 密钥。密钥可能很难轮换,用户可能会提取它们。您可能还想向已在AWS 之外(例如在您的公司目录或 IdP 中)定义身份的用户授予访问权限。或者,您可能需要向第三方授予对您账户的访问权限,使其能够对您的资源执行审核操作。