最近读了《混沌工程》一书，除了对混沌工程这门学科的知识点进行学习外，针对大型的分布式系统的管理也有一些想法
这里摘录一些比较好的观点，部分会与社会管理进行了类比，这里供大家参考：
1. 所谓延迟：即服务的实时性，解决思路如下：
（1）纯数据类型的处理可以使用大数据引擎的实时计算，
（2）文件等复杂类型的逻辑处理可以通过减少处理环节（kakfa、RPC）、减少IO（网络或者磁盘）次数
对应社会的管理：
（1）大数据引擎的实时计算——纯业务性质的事物请专业团队完成（专业的人做专业的事）
（2）减少处理环节——精简参与流程的人员数目（人少好办事）
（3）减少IO次数——即一次问好，一次办完（政府窗口提倡的“最多跑一次”活动）
2.所谓资源成本的最小化：即用较少的资源完成高效的服务，解决思路如下：
（1）获取系统消耗的性能数据
（2）找到性能消耗的大头、不合理的点
（3）按照裁撤一批资源、删减一批服务、整合一批服务的原则优化成本
1.所谓系统正常响应：即客户端请求的服务可以在预期内返回
（1）正常情况下的回应——提供完整服务
（2）异常情况下的响应——提供部分服务——消峰（kafka队列）、保中心（推荐功能、个性化功能）
对应社会的管理：
（1）提供完整服务——日常情况下提供全部服务
（2）消峰——疫情后的社保补交服务
（3）保中心——简化办事流程——疫情情况下水电气暖的服务，地震情况下的电信服务——基本无需办理
2.避免宕机的能力：高可靠
（1）分布式部署——K8S
（2）多地多中心部署 ——交行两地三中心（包括ES、数据库、DNS资源）
对应社会的管理：
（1）分布式部署——防空、电厂、粮食储备、应急物资
（2）多地多中心部署——后备指挥部
1.健康检查——自检、重启
2.代码级容错——异常处理
3.SRE监控——告警、投诉
对应社会的管理：
1. 定期人员换班（银行每日停止服务后的查账、清点）
2. 服务软件的重启、业务流程的重新办理（银行、公安的经典操作）
3. 监督人员、客户投诉
然而并不是所有的方面（性能、可用性、容错能力）都与微服务、分布式相同：
比如：
系统管理：微服务与性能的延迟性不完全一致
社会管理：各自团队——各自流程——耗时变长
系统管理：微服务、分布式服务与资源成本最小化不完全一致
社会管理：各自团队——资源冗余——资源变大（人、财、物又一套团队）
但微服务、分布式服务并不是性能优化的障碍
系统管理：微服务与可用性的系统正常响应基本一致，资源紧张下，只保证核心微服务就好，可以快速与其他服务切割
社会管理：资源紧张下，其他团队来支援核心团队——政府和事业单位部分停摆，转为防疫志愿者团队、扶贫团队
系统管理：分布式服务与可用性的避免宕机的能力基本一致，将服务部署在多个集群中，一个地区服务异常快速熔断、流量导流
社会管理：疫情初期，武汉停摆，全国医护人员支援武汉
那社会管理能否成为系统管理的借鉴呢？笔者认为是可以的，
就像社会会不断的发展和进步、新的理念会提出、改革永远在进行时
一个系统也在不断的更新功能、不断的满足客户需求，设计一个系统，不仅仅要考虑当下，还好考虑进行时、未来发展
1.建立“XX示范区”、“XX试验区”——部分区域灰度测试
分布式架构的好处在于可以快速的在部分功能上实现灰度测试、试运行，即在部分区域实现功能体验，减少影响范围
2.建立流程优化试点——“最多跑一次”改革
微服务——松耦合——高度协作
微服务——松耦合——专业的人做专业的事——不同的人员/团队维护不同的模块
松耦合——高度协作——外循环转内循环——契约测试要做好
社会管理与系统管理的相似点：
系统管理：任何组织所做的系统设计（广义的系统）的结构，将不可避免地复制这个组织信息沟通的组织结构
社会管理：任何社会管理单位所做的社会服务，将不可避免地复制这个社会管理单位的组织结构
所以：
1.微服务、分布式服务与社会管理相类似，值得坚持
2.项目高效程度与团队负责项目的广度正相关——🙆♂️的行政管理中心——人员的职责微服务——团队的职责高广度——架构越大沟通成本越高——效率越低——大仓——大团队管理
3.一个人设计的维护系统永远是他人/其他团队难以维护的——人员流动是检验项目的可维护性的抓手——实习生——ISV
4.新服务要从调研开始——灰度测试——数据支撑——客户返回——系统架构升级——全面落地