年初换了岗位，从开发转到sre了，之前没有想过做sre，在领导和同事的建议和推荐下（ps：在此感谢他们的关照），自己也想尝试下不同的岗位，所以选择试试sre。算了下已经在sre岗位4个月了，学习和接触到了很多东西，觉得有必要记录下来。
因为之前是开发岗位，主要是负责acm observability相关开发，现在转成sre以后，发现自己的角色从acm observability的开发变成了用户，很有意思，observability主要也是监控相关的技术，而sre当然也离不开监控，所以今天简单聊下，我从sre视角看开发：
- 应用是否暴露关键指标：sre人员需要监控应用以确保稳定性，就离不开应用的关键性能指标，应用一般需要提供一个端点供监控系统获取指标数据，比如you.svc.com/metrics
- 应用是否提供自检系统：应用应该暴露一个端点，方便其他服务检查应用是否正常工作，例如一个数据库应用至少能正常读写，才能对外提供服务
- 应用是否有高可用模式：如果其中一个实例挂了，应用是否能正常工作，一般需要提供HA功能
- 应用是否有必要的日志：应用需要提供不同级别的日志，比如在debug模式下能输出更详尽的日志，方便sre人员debug，且最好提供结构化的日志如json，方便解析和分析
- 应用是否有降级模式：应用需要提供降级模式，当系统负载不足时能自动降级确保服务的基本功能
- 应用是否提供维护窗口：应用需要提供维护窗口，方便sre对服务进行维护或者升级等
- 应用最好是无状态：无状态应用方便扩展和迁移而不担心状态问题
- 应用是否有完整的自动化测试：比如高覆盖率的ut，一键运行的e2e
- 应用是否有cli：必要的cli是自动化的基本条件之一
- 应用是否提供api：和命令行cli一样，提供api方便扩展和自动化，不是必须的，但是能有api最好
- 应用是否能自动化部署：最好能提供部署日志，方便后期查看，我理解自动化一切是sre的目标之一，不能自动化部署的应用会是sre的噩梦之一
- 应用是否有考虑升级和卸载：比如提供必要的升级或者迁移工具，卸载时不遗留相关服务和文件等，当然必要的升级和卸载日志对sre也很有用
- 应用是否小而精美：应该在保证必要功能的前提下，保持精简，而不是提供一个大而全的应用，干好一件事就很了不起
- 应用是否提供必要的文档：必要的文档是部署、熟悉和debug应用的基本条件之一，比如提供相应的troubleshooting方便sre人员能快速的定位和解决问题
- 应用是否能容器化：能容器化的应用，方便sre能快速部署和维护应用而不担心环境不一致的问题
- 应用部署是否设置了资源限制：对应用设定必要的资源限制是很有用的，防止应用使用过多资源导致其他关键服务不可用
- 应用是否有性能测试数据：必要的性能测试数据方便sre人员做容量规划等
- 应用是否提供必要的审计日志：比如谁访问了什么资源，做了什么操作等
以上只是我近期换岗sre以后的一些感想，主要也是因为角色转变，再次看开发就发现自己之前很多地方都没有考虑到，记录下来也算是一种成长，另外这里没有提到安全相关的话题，是因为安全这块我不太熟悉，但是有必要在前期规划时考虑安全问题，本次就先分享到这里，下次分享一些alert相关的内容。
:) 未完待续……
LEo at 00:12
