划重点：赵成老师的运维体系管理课精华

划重点：赵成老师的运维体系管理课精华

我们专栏的四大模块分别是：

应用运维体系建设

• 为什么Netflix没有运维岗位？

  合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
  

• 微服务架构时代，运维体系建设为什么要以"应用"为核心？

  微服务的架构模式下，我们的运维视角一定要转到应用这个核心概念上来，一切要从应用的角度来分析和看待问题。
  

• 标准化体系建设（上）：如何建立应用标准化体系和模型？

  标准先行，标准先行，标准先行，于纷繁复杂中抽象出标准规范的东西，是我们后续一系列自动化和稳定性保障的基础。
  

• 标准化体系建设（下）：如何建立基础架构标准化化及服务化体系？

  我们要做的事情，可以归纳为两步：第一步是基础架构标准化，第二步是基础架构服务化。
  

• 如何从生命周期的视角看待应用运维体系建设？

  从生命周期入手，划分阶段，提炼属性，理清关系，固话基础信息，实现运维场景。
  

• 聊聊CMDB的前世今生

  新的时期，对于CMDB的理解也要与时俱进，这个时候，思路上的转变，远比技术上的实现更重要。
  

• 有了CMDB，为什么还需要应用配置管理？

  CMDB是面向资源的管理，是运维的基石，应用配置管理是面向应用的管理，是运维的核心。
  

• 如何在CMDB中落地应用的概念？

  运维能力的体现，一定是整体技术架构能力的体现，割裂两者单独去看，都是没有意义的。
  

• 如何打造运维组织架构？

  运维在这个过程中，就好像串起来一串珍珠的绳子，将整个平台技术的不同部门，甚至开发团队给串联起来，朝着发挥出整体技术架构运维能力的方向演进。
  

• 谷歌SRE运维模式解读

  SRE是一个岗位，但更是一种运维理念和方法论
  

• 从谷歌CRE谈起，运维如何培养服务意识？

  是不是有服务心态，表现在我们的做事方式上，就是我们是否能够站在对方的角度问题、解决问题。
  

效率和稳定性最佳实践

• 持续交付知易行难，想做成这事你要理解几个关键点

  配置管理、提交管理、构建和部署发布是持续交付的重中之重，是关键路径，是从开发代码开始，到发布上线的必经之路。
  

• 持续交付的第一关键点：配置管理

  勿在浮沙筑高台，我们做工具平台或系统，一定要重视基础的建设。
  

• 如何做好持续纠纷中的多环境配置管理？

  环境配置管理主要是针对应用对基础设施和基础服务依赖关系的配置管理。
  

• 开发和测试争抢环境？是时候进行多环境建设了

  我们在线下环境区域内，一般会建设三套环境：集成测试环境，开发测试环境和项目环境。
  

• 线上环境建设，要扛得住真刀真枪的考验

  预发环境就像是球类运动员，他们平时可以在训练场进行训练，但是正式比赛前，一定是要到正式比赛场地提前适应场地或者热身。
  

• 人多力量大vs两个披萨原则，聊聊持续交付中的流水线模式

  开发模式的选型原则：一看这几种模式的适用场景，二看我们实际的使用场景是怎么样的。
  

• 持续交付流水线软件构建难吗？有哪些关键问题？

  容器的高效实用，一定是建立在更加完善和高度标准化的体系之上，否则工具只会越用越乱。
  

• 持续交付中流水线构建完成后就大公告成了吗？别忘了质量保障

  需要明确的是，在持续交付过程中，我们还要做很多与质量保障相关的工作，比如各类功能测试和非功能测试。
  

• 做持续交付概念重要还是场景重要？看"笨办法"如何找到最佳方案

  我们所采取的手段，其实都是笨办法：即找到问题，分析问题，调研解决方案，讨论碰撞，然后慢慢探索和实践，找出最合适我们的方案。
  

• 极端场景下，我们应该如何做好稳定性保障？

  对于稳定性而言，用户访问模型才是关键，这个摸不准，只有技术是没有用的，这就更需要我们才能深入业务，理解业务。
  

• 稳定性实践：容量规划之业务场景分析

  容量规划，就是对复杂业务场景分析，通过一定的技术手段，来达到对资源合理扩容、有效规划的过程。
  

• 稳定性实践：容量规划之实践压测系统建设

  压力测试四维度：压测粒度、压测接口及流量构造方式、试压方式、数据读写。
  

• 稳定性实践：限流降级

  限流降级的难点和关键还是在于整体技术栈的统一，以及后期对每个应用限流降级资源策略的准确把握和配置。
  

• 稳定性实践：开关和预案

  开关，主要是针对单个功能的启用和停止进行控制，或者将功能状态在不同版本之间进行切换。预案，可以理解为让应用或业务进入到某种特定状态的复杂方案执行。
  

• 稳定性实践：全链路跟踪系统，技术运营能力的体现

  我们做全链路跟踪系统，要解决首要问题就是在纷繁复杂的服务调用关系中快速准确定位问题。
  

• 谈谈我对故障的理解

  系统正常，只是该系统无数异常情况下的一种特例。故障永远只是表面现象，其背后技术和管理上的问题才是根因。
  

• 故障管理：故障定级和定责

  我们将故障等级设置为P0-P4这么5个级别，P0为最高，P4为最低
  

• 故障管理：鼓励做事，而不是处罚错误

  这样的规则建议通过设定高压线的方式让团队牢记心中，就像酒后不开车一样，简单明确。
  

• 故障管理：故障应急和故障复盘

  凡是没有演练过的预案，都是耍流氓。功夫要下在平时，注意建设各种工具和平台，同时要尽可能的考虑和模拟各种故障场景。
  

• 唇芒齿寒，运维与安全

  在双方（运维与安全）工作的协作上，我一直认为运维不能只是被动响应，而应该主动与安全合作，共建安全体系，与运维体系融合，把防线建设好，从源头控制。
  

云计算时代的运维实践

• 为什么蘑菇街会选择上云？是被动选择还是主动出击？

  如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择。
  

• 为什么混合云是未来云计算的主流形态？

  不管如何选择和使用，我们一定还是要以满足业务场景为出发点，脱离了这一点，单纯追求技术深度和复杂度是没有意义的。
  

• Spring Cloud：面向应用层的云架构解决方案

  Spring Cloud 不仅仅是微服务治理解决方案，他同时还是面向应用层的云架构解决方案。
  

• 以绝对优势立足，从CDN和云存储来聊聊云生态的崛起

  利用云计算的优势，拥抱变化，才能为我们业务发展和创新带来更多的可能性。
  

• 量体裁衣放得最优解：聊聊页面静态化架构和二级CDN建设

  公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”
  

• 云计算时代，我们所说的弹性伸缩，弹的到底是什么？

  对于运维，一定要准确识别出日常运维过程中不同的运维对象，然后再进一步去分析这个对象所对应的运维场景是什么？进而才是针对运维场景的分解和开发。
  

个人成长

• 我是如何走上运维岗位的？

  这样的一个发展过程并不是我刻意设计过多的，机会也不是刻意争取到的，就是平时多做一点，做的认真一点，确保最终能拿到结构，而且稍微努力一下，尽量拿到比预期好的一些结果。
  

• 云计算和AI时代，运维应该如何做好转型？

  不断的学习和提升自己的技能，保持对于技术发展趋势的敏锐性，及时作出调整和应对，才是根本的解决之道。
  

• 运维需要懂产品和运营吗？

  我们强调的是运维要有产品和运营意识，总结起来最本质的两点，第一，就是能将需求讲清楚，第二，能将产品进行推广落地。
  

• 冷静下来想想，员工离职这事真能防住吗？

  技术管理者，一定要重点关注人，而不仅仅是事情，这点是做技术骨干和技术管理者之间的最大区别，也是思路转变的第一步。
  

• 树立个人品牌意识：从背景调查谈谈职业口碑的重要性

  背景调查的过程不可控，但是我们自身的表现却从来都是可控的。