高效运维社区devops，在职业规划上devops和网络该怎么选？
不太了解比现在做什么。
如果你现在做软件开发或测试，去做DevOps，未来很多公司去实施DevOps，钱途会很不错。
如果你现在从事网络，转型其他岗位不是很容易，继续做好网络也不错；如果是运维转DevOps相对容易些。
想知道程序员眼里的DevOps文化是怎样的？
DevOps主要体现出两方面的理念：开发运维一体化和自动化。
一体化的着眼点主要是让程序员有大局的观念，不要只顾着写好自己模块的代码就交差，而是要从全局的角度考虑自己的代码对上下游有什么影响，在实际的生产环境中会不会有问题，在极端情况下会不会对服务性能、安全等方面产生影响等。
从自动化的角度看，程序员既然拥有掌控代码的能力，就应该具有不做重复事情的理念。计算机的发明，就是用来解决人类，把一些重复的事情交给计算机，只要提供指令，计算机就可以又快又好地一遍遍的执行。软件从开发到上线，中间经历很多步骤，如果因为修改一个小bug，而一遍遍地手工重复上线过程，一来影响效率，二来人手操作难免失误，所以DevOps的提出，就是把这个流程自动化，可以一切按照既定的流程走，避免各种意外发生。
华为adm是什么？
华为ADM是华为云服务中的一个云原生应用开发管理平台。原因是：华为ADM为开发人员提供全周期协调一体化开发、构建、测试、部署、运维全流程一站式的云原应用开发和运营解决方案，并且它可以与华为云其他产品深度融合，包括云容器引擎（CCE）、DevCloud代码构建、CodeHuawei代码托管等。华为ADM在开发过程中可以通过DevOps方法实现高效率和小步迭代的开发，同时支持多维度的性能监控和问题排查，提升了开发测试效率和稳定性。此外，华为ADM可以与华为云其他产品深度集成，包括云数据库、云缓存、云负载均衡等，从而满足各种应用场景的需求。
大家都怎么理解落地微服务？
首先我们尝试用一段话解释一下微服务的概念，微服务区别于讲所有的服务，数据库访问等业务及中间层代码打在一个jar或者war包内的all in one的体系结构，以业务服务及领域模型的组合为单元拆分出可独立部署，独立运行，独立风险控制的系统组件应用的结合体。微服务拥有业务服务（可以理解为spring mvc中的service）及领域模型（可以理解为spring mvc中的model）为闭环，其本身的微服务系统所提供的服务业务边界清晰，生命周期独立且可自运行，可隔离，可追踪。
所有的服务融合在一个业务程序内，采用all in one的打包方式组成一个jar或者一个war包，并且访问同一个mysql数据库，简单粗糙，服务之间调用关系由于是在一个代码包内，可以随意互相应用，业务关系不清晰，而且部署在一起，一旦一个服务或者对应的数据库产生问题，则全盘故障。
于是我们把系统做了微服务化的拆分，以服务为单位将其变成一个分布式的系统。
网关接入系统负责接收对应的web请求，转发给对应后面的业务服务系统处理对应的业务并接收返回转发给前端。
后面的业务服务系统各司其职，每个系统只负责自己业务范围内的职责，比如商品系统仅服务商品相关的服务，创建，更新，查询，
上下架等整个的生命周期并被购物车系统依赖，服务系统之间的逻辑关系清晰，且不同系统间只能通过对方提供的接口做访问，管理方便，
每个系统拥有自己独立部署服务器，拥有自己的存储数据库，故障可隔离，配合日志，消息，监控，配置中心等分部署微服务下的配合组件做到一个可监控，可隔离，又可通信的服务体系。
微服务的落地技术有很多，但总体来讲还是可以用几个简单的点去做分类，微服务的框架目前开源的用的最多的是spring cloud，另外有人肯定会说为什么不是dubbo，那其实dubbo仅仅是解决了微服务技术中的一部分问题，例如服务通信，负载均衡，服务注册发现等，但是他没有解决降级限流，熔断控制，服务路由等问题，还需要自己实现或者结合一些第三方组件，因此spring cloud是真正意义上闭环完整的实现了所有微服务的落地功能技术。
有了spring cloud这一整套的服务治理方案，还缺少服务部署工具，现在流行的微服务部署方式是将服务打成docker镜像，在k8s上面部署，当然还可以集成jenkins，实现DevOps的整体技术方案，能够快速的实现服务上线，异常回滚以及灰度发布等需求，从而实现一整套的微服务自动化开发运维服务体系。
研发和运维之间该怎么协同合作？
之前在传统运维时代，开发同学把代码开发好之后交给运维，他的工作就结束了，但现在在云原生时代，他要负责去配置发布流水线等工作，这样一来他的工作量其实增加了很多，所以最开始我们DevOps的落地阻力很大。
我们持续不断降低运维平台使用门槛，开发和运维通过运维平台实现了标准化对接，减少了非常多的沟通成本，大幅提升了效率。开发同学获得收益之后，DevOps这种方式才慢慢得到认可。所以在协同过程中，我们这边确实花了很多时间和精力，但最后还是取得了想要看到的收益。 ——吴召军
