ops_doc

文档制作: 雪松

更新日期: 2016-04-28

本文档手册希望可以达到通俗易懂, 方便运维人员使用, 错误在所难免, 还望指正！

github更新下载地址: https://github.com/liquanzhou/ops_doc

请勿删除信息, 转载请说明出处, 抵制不道德行为

总是听到有说:

1.运维累，背锅，薪资低?

运维没做好，没有核心技能，肯定是累且背锅，薪资涨不上去。
各行各业皆是如此，不仅仅是运维行业。

2.运维开发的自动化取代运维?

运维开发只是运维的一个技能分支，不需要神话运维开发。
大多是培训招生鼓吹，运维开发淘汰运维。
只做运维开发，不了解运维业务，做的系统平台怎么可能好用？
不了解业务，平台实现无法统一标准，统一流程。

3.云平台取代运维?

云商资源是工具，业务问题是云商无法解决干预的，需要专业运维人员使用拼接。

4.人工智能取代运维?

人工智能类似GPT取代运维更是不可能，只会更好的帮助运维工作。

做好本职工作:

切勿浮躁，避免被他人干扰。

不了解运维痛点，不解决业务难题，无论运维，SRE，运维开发都是做不好的。

见过运维技术好，搭建各种服务效率，各种参数都知道，可唯独没有任何标准化思维，导致工作累，业务又频繁故障。

运维岗位比其他技术岗位更了解技术架构全链路，很多开发和架构解决不了的问题只能依靠运维。

做运维部门核心技术人员，精英运维，核心能力才是不可替代性。

不要区分运维和运维开发，两方面能力都重要。

针对运维岗位的一点经验看法:

坚持本心，做好技术，技术到了一定程度，多考虑业务。核心是用技术解决业务上的难题，想办法从根本原因解决问题。不能只解决表面问题。少一些花里胡哨的技术和流程。多花心思考虑实用性，稳定性，运维可协同维护，开发的用户体验才是王道。

统一业务标准化: 环境一致，数据一致，流程一致。最后才是自动化的实现。

业务可观测: 故障第一时间可以报警，链路可追踪，监控图表可事后分析。减少无用信息，快捷有效。

业务稳定性: 稳定是核心标准，处理故障后，多分析原因始末，多和业务方和架构师探讨交流，积累架构经验。想各种办法方案从根本上解决故障点。