文档制作: 雪松
更新日期: 2016-04-28
本文档手册希望可以达到通俗易懂，方便运维人员使用，错误在所难免，还望指正！
github更新下载地址: https://github.com/liquanzhou/ops_doc
请勿删除信息，转载请说明出处，抵制不道德行为
运维没做好，没有核心技能，肯定是累且背锅，薪资涨不上去。各行各业皆是如此，最底层都是一滩烂泥，不仅仅是运维行业。小事(运维处理个磁盘，处理个内存报警)其实就能体现出来能力. 太多运维都是处理表面问题，根本不去真正了解需求，也不去思考解决办法，不用心去把事情做漂亮，成长也基本止步，指望这类人去搞点创新，解决点难题，基本不可能，反过来想这种人怎么可能高工资? 做任何行业都一样，重要的是思考: 怎么差异化，怎么脱颖而出，做出与众不同，怎么做到核心精英.
运维开发只是运维的一个技能分支，不需要神话运维开发。大多是培训招生鼓吹，运维开发淘汰运维。只做运维开发，不了解运维业务，做的系统平台怎么可能好用？ 不了解业务，平台实现无法统一标准，统一流程。
云商资源是工具，业务问题是云商无法解决干预的，需要专业运维人员使用拼接。
人工智能类似GPT取代运维更是不可能，只会更好的帮助运维工作。高级运维要在架构能力，主导能力，灵活运用，解决各种复杂难题，并不是人工智能直接给出的建议就能解决。
坚持本心，切勿浮躁，避免被他人干扰。
不了解运维痛点，不解决业务难题，无论运维，SRE，运维开发都是做不好的。
干活前多统计，多准备，多思考规避问题，多考虑简化方案。干的时候先挑大块的标准化的方式搞
见过运维技术好，搭建各种服务效率，各种参数都知道，可唯独没有任何标准化思维，导致工作累，业务又频繁故障。
运维岗位比其他技术岗位更了解技术架构全链路，很多开发和架构解决不了的问题只能依靠运维。
做运维部门核心技术人员，核心技术能力才能让自己不可替代。不要区分运维和运维开发，两方面能力都重要。
统一业务标准化: 环境一致，数据一致，流程一致。最后才是自动化的实现。
业务可观测: 故障第一时间可以报警，链路可追踪，监控图表可事后分析。减少无用信息，快捷有效。
业务稳定性: 稳定是核心标准，处理故障后，多分析原因始末，多和业务方和架构师探讨交流，积累架构经验。
好多公司运维部门都是积极使用k8s，但没有规划的使用又会引起好多不易维护的难点痛点:
1.缺少自动化，导致繁重的人肉维护大量yaml文件
如果可以，k8s内部的yaml尽量规避任何人肉改动，全部发布系统标准化生成(deployment，service，hpa，inrgess，vs等等全部统一与模板一致).规避复杂的7层路由策略在k8s中做.尽可能对外入口统一，k8s流量接入与deployment一一对应，就可以实现k8s内部全部标准化自动生成
2.无法统一注册中心，每组k8s有各自的etcd注册，两组k8s中服务互联就会有麻烦，开发可能更喜欢服务框架依赖的各自注册发现方式.导致流量接入混乱.流量平滑，维护复杂，多语言服务互联障碍.
这个情况，要看实际业务场景，多与开发架构师沟通方案，如何推动统一注册发现机制，让开发互调流量和运维的流量接入统一
1.优先解决棘手的业务稳定问题
2.多维度监控，确保第一时间发现问题，定位问题根因
3.多与架构交流，沟通稳定性解决方案
4.统一打包发布的标准流程
5.提升自动化工作范围
6.成本控制
7.精准报警，清理无用大量报警
8.清理无用5xx错误，程序error干扰
1.服务全部标准化,统一打包和部署方式
2.监控图精准易用
3.监控报警灵敏,避免重复检查次数,触发即报警
4.报警维度健全
5.尽可能自动化
6.自动扩容(需要服务上下线平滑)
7.cdn和存储主备自动切换
8.跨境质量
1.程序日志级别可靠,通过error数量报警
2.程序状态码标准,通过5xx状态码报警
3.核心服务降级
1.统一健康检查接口
2.统一下线接口
3.全局服务统一注册,不区分语言和服务类型
4.注册有权重
5.调用方可根据5xx错误次数进行权重熔断
6.发布过程平滑,启动预热(可基于权重小流量)
7.服务调用打点,调用服务名,被调用服务名,uri,状态
8.日志规范可收集
9.链路跟踪,前后端串联
10.限流,应对雪崩场景
11.响应时间
12.mysql限制全局兜底limit
13.ABtest能力