开发自动化操作和维护架构的六个要素
第一点:架构独立性
任何体系结构都是为了满足特定的业务需求而创建的。是否能在满足业务需求的同时兼顾运维对架构管理的非功能性需求。那么我们有理由认为这样的架构是有利于运维的。
从运维的角度来看，所需的架构独立性包括四个方面:独立部署、独立测试、组件化和技术解耦。
独立部署
指源代码，可以部署、升级、扩展等。根据管理要求便于操作和维护，并可区分地理分布进行配置。服务之间的相互调用是通过接口请求实现的，部署独立也是运维独立的前提。
独立测试
运维可以通过一些方便的测试用例或工具来验证业务架构或服务的可用性。具有这种能力的业务架构或服务，使得运维可以独立上线，每次发布或变更都不需要开发人员或测试人员的参与。
部件规格
意味着在同一个公司内有一个很好的相关技术的框架支持，避免不同的开发团队使用不同的技术栈或组件，导致公司内部技术架构失控。
这种做法可以限制运维对象的无序增加，保持运维对生产环境的控制。同时也可以让运维保持更多的精力投入去围绕标准组件做更多有效率有质量的建设工作。
技术脱钩
它指的是减少服务之间的相互依赖，也包括减少代码对配置文件的依赖。这也是微服务、独立部署、独立测试、组件化的基础。
第二点:友好部署
DevOps有很大篇幅讲持续交付的技术实践，希望从头到尾打通开发、测试、运维的所有技术环节，从而达到快速部署、交付价值的目的。可见，部署是日常运维工作中非常重要的一部分，属于计划性工作，重复度高，必须提高效率。
要实现高效可靠的部署能力，需要做好统筹规划，确保部署和运行阶段的全方位运维控制。与部署友好性相关的内容有五个纬度:
CMDB构型
在每次部署操作之前，运维部门需要清楚地把握应用与架构和业务之间的关系，以便更好地了解和评估全局的工作量和潜在风险。
在智云自动化运维平台中，我们习惯将业务关系、集群管理、运行状态、重要级别、架构层等配置信息作为运维的管理对象管理在CMDB配置管理数据库中。这种管理方式的好处显而易见。集中存储运维对象的配置信息，将为未来运维、监控、告警的自动化能力建设提供大量的配置数据支持和决策辅助。
环境配置
在运维标准化程度较低的企业，阻碍部署交付效率的原罪之一就是环境配置，这也是容器化技术主要希望解决的运维痛点之一。
在腾讯的运维实践中，通过枚举环境和运维操作相关的资源集合，结合自动初始化工具，实现开发、测试、生产三大环境的规范化管理。
依赖性管理
解决应用软件对库和运行环境依赖的管理。在织云的实践经验中，我们通过将依赖库文件或环境的配置打包为一个整体，前后执行脚本，利用包管理解决不同环境下的应用软件部署问题。业内有较轻的集装箱化发货方式，也是不错的选择。
部署模式
持续交付的原则是指建立一个可靠的、可重复的交付管道，我们也根据这个目标强力规划应用软件的部署。行业内有很多案例可以参考，比如Docker的Build，Ship，Run，比如通过配置编织云的描述，标准化流程的一键部署等等。
发布自测
发布自测包括两个部分:
应用程序的轻量级测试；
出版/变更内容的校对。
构建这两种能力，满足不同运维场景的需求。比如在增量发布中，运维人员可以快速获取变更文件md5或者检查对比相关进程和端口的配置信息，保证每次发布变更的可靠性。
同样，轻量级测试是为了满足发布时服务可用性检测的需求。这一步可以检测服务的连通性，并运行一些主干测试用例。
灰色上线
《日常运维三十六计》中有一句话:对于不可逆的删除或修改，尽量推迟或减缓执行。这就是灰度的思想。无论从用户、时间、服务器等纬度的灰度，都希望将线上运营的风险降到最低。业务架构支持灰度发布的能力，降低了应用部署过程中的风险，对运维更加友好。
第三点:可操作性
运维心目中最理想的微服务架构，肯定是运维强的那种。没有可操作性的应用或架构，不仅给运维团队带来骂名，也深深伤害了他们的职业发展，因为维护一个没有可操作性的架构，根本就是浪费运维人员的生命。
根据操作规范和管理规范，可操作性可概括为以下七点:
结构管理
在微服务架构管理中，我们提出将应用二进制文件从配置管理中分离出来，从而达到独立部署的目的。
对于独立的应用程序配置，有三种管理方法:
文件模式；
配置项模式；
分布式配置中心模式。
限于篇幅，我们不讨论以上三种方法的优缺点。不同的企业可以选择最适合的配置管理方式，关键是要求所有业务使用一致的方案，这样运维就可以搭建配置管理的工具和系统。
版本管理
DevOps，连续交付的八大原则之一，“将一切置于版本控制之下”。就运维对象而言，要想管理好，必须能描述清楚。
与源代码管理的需求类似，运维也需要对日常操作对象进行脚本化，比如包、配置、脚本等，以便在运维系统完成自动化操作时，准确选择操作对象和版本。
标准操作
日常运维中有大量重复性的工作要做。从精益思维的角度来看，这里有很大的浪费:学习成本、无价值的操作、多余的脚本/工具、人为执行的风险等等。
如果能在企业内部形成统一的操作标准，比如文件传输、远程执行、应用启动和停止等。，这些都是标准化、集中化、一键式的操作，运维的效率和质量都会大大提高。
进程管理
包括应用安装路径、目录结构、规范进程名、规范端口号、起止模式、监控方案等。，都属于流程管理的范畴。做好流程管理的全局规划，可以大大提高自动化运维程度，减少计划外任务的发生。
空间管理
做好磁盘空间的使用管理是保证业务数据有序存储和减少计划外任务发生的有效手段。
需要提前做好规划:备份策略、存储方案、容量预警、清理策略等。，辅以有效的工具，让这些工作不再困扰运维。
日志管理
日志规范的实施和执行需要研发的密切配合，实践中获得的经验和理想运维中的日志规范应该包括这些要求:
业务数据与日志分离。
日志与业务逻辑是分离的。
统一日志格式
返回代码和注释很清楚
可用业务指标(请求量/成功率/延迟)
定义关键事件
输出水平
管理方案(存储时间、压缩备份等。)
当能够实现上述条件的日志规范时，开发、运行和维护可以相应地获得更好的监控和分析能力。
集中控制
运维工作本来就容易分成不同的部分，比如发布变更、监控分析、故障处理、项目支持、多云管理等。我们呼吁建立一站式的运维管理平台，让所有的工作信息都可以连接和传递，从而消除信息孤岛或人工传递信息带来的运营风险，提高整体运维管理的效率和质量。
第四点:容错和容灾
腾讯技术运营(运维)中的四个责任:质量、效率、成本、安全。质量是保证的第一位。从架构的角度来看，运维眼中理想的高可用性架构设计应该包括以下几点:
负载均衡
无论是软件还是硬件的均衡解决方案，从运维的角度，我们总是希望业务架构无状态，路由寻址智能化，自动实现集群容错。
在腾讯路由软件多年的实践中，软件负载均衡方案得到了广泛应用，为业务架构高可用的实现做出了巨大贡献。
可调度性
在移动互联网时代，可调度性是容灾容错极其重要的运维手段。当业务遇到无法立即解决的故障时，将用户或服务转出异常区域，是在海量运营实践中屡试不爽的技能，也是腾讯QQ和微信保证平台服务质量的核心运维能力之一。
结合域名、VIP、接入网关等技术，架构支持调度的能力，丰富了运维管理的手段，具有更从容应对各种故障场景的能力。
住在不同的地方
异地多活动是数据高可用的需求，也是可调度的前提。根据不同的业务场景，技术实现的手段没有限制。
腾讯的社会实践可以参考周晓军老师的文章《两亿QQ用户背后的架构设计与高效运营》。
主从切换
在数据库的高可用性方案中，主从切换是最常见的容灾方案。通过业务逻辑中读写分离，结合智能路由，实现无人值守主从切换的自动化，无疑是架构设计给DBA最好的礼物。
灵活可用性
“先稳住再优化”是腾讯海量运营思路之一，也为我们做业务架构高可用设计指明了方向。
在业务量骤增的情况下，如何最大程度地保证业务的可用性？这是建筑规划设计中不可回避的问题。巧妙设置灵活的开关或内置逻辑自动拒绝超额请求，可以保证后端服务在关键时刻不雪崩，保证业务架构的高可用。
第五点:质量控制
保证和提高业务质量是运维努力的目标，监控能力是我们实现目标的重要技术手段。运维部门希望该架构能为质量监控提供便利和数据支持，要求如下:
指示器测量
每一个架构都必须可以用指标来衡量，同时我们希望最好只有一个唯一的指标衡量。对于日益完善的业务立体监控，监控指标的数量会成倍增加。因此，我们希望架构只有一个指标度量。
基本监控
指网络、专线、主机、系统的低级指标能力。这些监测点大多是非侵入性的，很容易收集数据。
在一个自动化运维能力健全的企业中，基础监控产生的大部分告警数据都会有所收敛。同时，这部分监测数据将为高层业务监测提供数据支持和决策依据，或者被打包为更贴近上层应用场景的业务监测数据，如容量、多维指标等。
组件监控
腾讯习惯把开发框架、路由服务、中间件称为组件。这种监控介于基础监控和业务监控之间。运维往往希望在组件中嵌入监控逻辑。通过组件的推广，提高组件监测的覆盖面，获取数据的成本适中。如果使用路由组件的监控，运维可以获得每个路由服务的请求量、延迟等状态和质量指标。
业务监控
业务监控的实现方式可以分为主动监控和被动监控，可以通过侵入式和旁路式实现。这种监控方案需要开发的配合，涉及到编码和架构。
通常情况下，业务监控的指标可以概括为三个指标:请求量、成功率和延迟。实现的方法有很多，如日志监测、流数据监测、波浪测量等。业务监控是高层次的监控，往往可以直接反馈业务问题。但要想深入分析问题的根源，必须结合必要的运维监控管理规范，如返回码定义、日志协议等。在设计业务架构时，要提前考虑运维监控管理的需求，范围要全局规划。
全链路监控
基础设施、组件和业务的监控手段更侧重于点监控。在分布式架构的业务场景中，必须考虑对服务请求链路的监控。
基于唯一的事务ID或RPC调用关系，通过技术手段还原调用关系链，然后通过模型或事件触发监控告警，反馈服务链路的状态和质量。这种监控方式属于监控的高级应用，在规划业务架构时也需要预先规划和代码嵌入。。
质量评估
任何监控能力的提升和质量的优化都需要一个闭环管理，而考核就是一个很好的手段。从监控覆盖面、综合指标、事件管理机制到报告考核评分，运营和开发可以共同打造一个持续反馈的质量管理闭环，让业务结构不断进化和完善。
第六点:性能成本
在腾讯，所有的技术运营人员都肩负着一个重要的职能，那就是保证合理的业务运营成本。为此，我们必须对应用吞吐性能、业务容量规划和运营成本有相应的管理方法。
吞吐量性能
在DevOps持续交付方法论中，测试阶段的非功能需求测试最重要的一点就是架构吞吐性能的压力测试，以保证应用上线后业务能力的健康。
在腾讯的实践中，性能压力测试并不局限于测试阶段。我们将结合路由组件的功能来测试服务模块和服务集的真实请求，从而建立服务能力模型的基准。还从侧面提供数据来论证业务架构的吞吐量性能是否满足成本评估的要求，利用不同服务之间性能数据的比较来促进架构性能的持续改进。
容量规划
英文单词“capacity”可以翻译为:应用性能、服务能力和总服务请求。运维能力规划是指在应用性能达标的前提下，基于总的服务请求进行合理的服务能力规划。
生产费用
降低运营成本对于公司来说就是减少了现金流的投入，对于企业的价值不亚于质量和效率的提升。
腾讯专注于社交网络、UGC、云计算、游戏、视频等富媒体服务。，而且每年消耗的带宽、设备等运营成本金额非常巨大。运维优化运营成本往往涉及产品功能和业务架构的优化。因此，理想的运维业务架构设计需要有足够的成本意识。
总结
本文纯粹是我从运维角度对微服务架构设计的一点拙见。为了实现运维价值最大化，保证业务质量、效率、成本的全面提升，业务架构这块硬骨头还得啃。
运维人员需要对架构有所了解，他们可以从不同的角度对业务架构提出建议或需求，这也是DevOps精神所倡导的。开发和运维协同工作，不断优化最佳业务架构。