53 lines
5.8 KiB
Markdown
53 lines
5.8 KiB
Markdown
|
||
## 快速迭代，快速上线
|
||
|
||
2020-10-1，CG
|
||
|
||
今天看到一篇ops间dev的问题，基本上是工作中常见问题，有意思
|
||
|
||
```
|
||
有些固定上线时间的项目，可能因为技术方案变化，导致测试时间压缩，最终导致上线出问题，而由运维来背锅。
|
||
为保住KPI，运维有很多心里话想和研发测试说一说：
|
||
- “敏捷开发，频繁交付”的KPI，真不是增加运维人手就能解决的，需要自动化回归的支持，需要自动化上线的支持
|
||
- “上线失败，快速回滚”的KPI，真不是增加运维人手就能解决的，需要回滚方案的支持，而回滚方案真的测试过么
|
||
- “快速扩容，快速响应”的KPI，真不是增加运维人手就能解决的，需要架构设计的支持（很多系统无法水平扩展，来了机器，无法扩容），需要快速部署的支持，需要服务发现的支持（所有上游修改配置重启肯定是不行的），需要压力测试和容量评估的支持
|
||
- “系统高可用”的KPI，真不是增加运维人手就能解决的，需要优雅降级的支持，需要架构设计的支持，如何评判系统是否高可用？这个简单，关掉线上任何一台机器试试，看用户服务是否受影响，如果受影响，研发哥哥们拜托了
|
||
- “快速故障报警”的KPI，真不是增加运维人手就能解决的，需要监控系统的支持（操作系统和运维层面的监控，我们可以实施，但错误日志、接口、业务的监控呢？），另外报警短信能少一点么，过度报警会让人变得“麻木不仁”的
|
||
- “快速故障定位”的KPI，真不是增加运维人手就能解决的，需要数据量化健康信息的支持（58到家的守望者平台做的还是不错的），需要快速诊断的支持（58到家的调用链跟踪系统做的还是不错的）
|
||
- “快速故障恢复”的KPI，真不是增加运维人手就能解决的，需要故障转移的支持，相信我们，故障发生时，如果运维人员不知道怎么抉择，且又必须做出抉择，这时的抉择往往是错的（我们能做的，是重启:smile:），我们也不想凌晨打给你们，但希望你们能实现自动化方案
|
||
- “内审合规”的KPI，真不是增加运维人手就能解决的，在资源允许的情况下，请不要手动删除任何资源，数据是很重要的资源。访问控制和权限申请的流程，真的不是限制大家，相反，哪一次数据的误删除，不是我们加班来恢复的？
|
||
|
||
我们的KPI都掌握在大家的手里，技术一家人，希望研发测试的同学理解。
|
||
```
|
||
|
||
|
||
**虽然有些戏说调侃，也问到了一些关于devops的痛点，我来回答下吧**<br>
|
||
---
|
||
|
||
- “敏捷开发，频繁交付”的KPI，真不是增加运维人手就能解决的，需要自动化回归的支持，需要自动化上线的支持
|
||
> **CG: 运维开发自动化运维平台，部署上线全流程自动化**<br>
|
||
|
||
- “上线失败，快速回滚”的KPI，真不是增加运维人手就能解决的，需要回滚方案的支持，而回滚方案真的测试过么
|
||
> **CG: 回滚方案应包含在部署文档里，失败可以分析原因，自动化运维应该考虑快速回滚**<br>
|
||
|
||
- “快速扩容，快速响应”的KPI，真不是增加运维人手就能解决的，需要架构设计的支持（很多系统无法水平扩展，来了机器，无法扩容），需要快速部署的支持，需要服务发现的支持（所有上游修改配置重启肯定是不行的），需要压力测试和容量评估的支持
|
||
> **CG: 不对，快速或弹性扩容运维应更多的考虑**<br>
|
||
|
||
- “系统高可用”的KPI，真不是增加运维人手就能解决的，需要优雅降级的支持，需要架构设计的支持，如何评判系统是否高可用？这个简单，关掉线上任何一台机器试试，看用户服务是否受影响，如果受影响，研发哥哥们拜托了
|
||
> **CG: 不对，研发应考虑架构级HA，运维应考虑部署级别A10 HLB+ HA，LVS，NGX，Haproxy，keeplived等SLB运维可以做的。**<br>
|
||
|
||
- “快速故障报警”的KPI，真不是增加运维人手就能解决的，需要监控系统的支持（操作系统和运维层面的监控，我们可以实施，但错误日志、接口、业务的监控呢？），另外报警短信能少一点么，过度报警会让人变得“麻木不仁”的
|
||
> **CG: 监控系统是运维职责，有些生产数据研发需要提供接口支持**<br>
|
||
|
||
- “快速故障定位”的KPI，真不是增加运维人手就能解决的，需要数据量化健康信息的支持（58到家的守望者平台做的还是不错的），需要快速诊断的支持（58到家的调用链跟踪系统做的还是不错的）
|
||
> **CG: 研发有这样的诊断工具当然是最好的，但这是理想状态啊，一是问题很难预设，二是客户需求不包含，三是这是运维工作，四这是计划外不符合敏捷的要求啊**<br>
|
||
|
||
- “快速故障恢复”的KPI，真不是增加运维人手就能解决的，需要故障转移的支持，相信我们，故障发生时，如果运维人员不知道怎么抉择，且又必须做出抉择，这时的抉择往往是错的（我们能做的，是重启:smile:），我们也不想凌晨打给你们，但希望你们能实现自动化方案
|
||
> **CG: 同上HA, 另认为运维就是重启的同学，要转型了！！！**<br>
|
||
|
||
- “内审合规”的KPI，真不是增加运维人手就能解决的，在资源允许的情况下，请不要手动删除任何资源，数据是很重要的资源。访问控制和权限申请的流程，真的不是限制大家，相反，哪一次数据的误删除，不是我们加班来恢复的？
|
||
> **CG: 生产上的运维权限分离不会产生这种问题，运维职责所在**<br>
|
||
|
||
**大家也自己问一问，关掉线上任何一台机器，用户服务受影响么？**
|
||
|