• 上线：代码上线、回滚、扩缩容；
• 配置：系统配置、应用配置；
• 网络：网络割接、设备更换；
• 其它：流量调度、服务切换、服务下线...
  {/gird-item}
  {gird-item}

• 制定变更审核流程；
• 制定变更相关方通知（群、邮件）；
• 制定变更回滚策略；
• 遵循测试、灰度、全量上线的规则；
• 下线变更要将服务器依赖处理干净，比如说挂着vip、有域名解析。
  {/gird-item}
  

• 服务：多机器、多机房；
• 数据：多备份、异地备份；
• 网络：多线路、多设备；
  {/gird-item}
  {gird-item}

• 自动切换 好于 手动切换；
• 无状态 好于 有状态；
• 热备 好于 冷备；
• 多机房 好于 单机房。
  {/gird-item}
  

• 系统：木桶原理计算系统的全链路容量、用量、余量；
• 模块：模块的容量、用量、余量；
• 机房：分机房的容量、用量、余量；
• 单机：用于反向计算机房、模块容量
  {/gird-item}
  {gird-item}

• 制定模块单机容量指标（比如QPS、连接数、在线用户数等）；
• 容量要考虑下行（读）、上行（写），考虑存储增量；
• 计算当前模块总容量，收集当前的用量，并对比容量计算余量；
• 系统总容量可以根据木桶原理，找到短板模块后，反向计算出来
  {/gird-item}
  

• 用户核心指标；
• 服务核心指标；
• 基础资源指标：服务器；
• 依赖资源指标：依赖db、依赖接口；
• 自动化巡检报告；
• 值班oncall安排；
  {/gird-item}
  {gird-item}

• DashBoard核心在于收敛、舍得；
• 自动化巡检的必要性在于异常侦测，预防故障。
  {/gird-item}
  

• 基础监控：CPU、内存、网络、IO；
• 应用监控：进程、端口；
• 业务监控：日志、业务埋点；
• 依赖监控：数据库、依赖接口...
  {/gird-item}
  {gird-item}

• 核心监控收敛成告警，并对告警进行分级，备注告警影响；
• 核心监控形成可排查问题的DashBoard；
• 告警的价值在于实时发现故障
  {/gird-item}
  

• 线路切换：移动、电信、联通线路切换；
• 机房切换：不同机房切换；
• 机器切换：机器故障时进行摘除；
• 服务降级：无法切换时，降低标准继续服务；
• 数据库切换：主从切换、读写切换；
• 网络切换：主备线路切换、链路切换；
  {/gird-item}
  {gird-item}

• 域名切换 好于 更换IP；
• 自动摘除 好于 手动操作；
• 自动切换 好于 手动切换；
• 考虑好雪崩事宜。
  {/gird-item}
  

• 服务分级：确定各服务用户角度的影响；
• 故障定级：制定故障定级标准；
• 制定故障通知、处理规范；
• 制定故障复盘，改进措施按时保量完成的规范；
  {/gird-item}
  {gird-item}

• 拥抱故障，同类故障不能重复发生。
• 实事求是，没有发生不等于不存在。
  {/gird-item}
  

• 开发、运维、临时权限；
• 安全上符合安全审计标准。
  {/gird-item}
  {gird-item}

• 最小权限原则
  {/gird-item}
  

• 统一共享知识文档；
• 统一共享各种脚本工具；
  {/gird-item}
  {gird-item}

• 标准化，统一化
• 理想的情况是“一站式运维平台”，一个平台涵盖所有工具操作。
  {/gird-item}
  

{gird-item}

• 主机名标准化；
• 日志存储标准化；
• 日志格式标准化；
• 域名使用标准化；
• 软件安装目录结构标准化；
• 服务及相关的组件使用命令标注化；
  {/gird-item}
  {gird-item}

• 主机名尽量能看出更多信息，比如服务、模块、机房等；
• 日志是排查问题的重要信息，一定要标准化，方便手工排查，更是为了以后用工具处理打下基础。
  {/gird-item}
  

• 服务器
• vip
• 域名
• 证书
• 代码
• k8s
• 数据库
• 中间件
  {/gird-item}
  {gird-item}

• 资源之间是有关系的，要建立有关系的资源管理
• CMDB系统
  {/gird-item}