CMM2过程域之风险与机会管理方法论实践

风险与机会管理（RSK）是CMMI2.0中的一个过程域，旨在识别潜在的风险或机会，以便策划处理风险或机会的活动，它是一个连续的、前瞻性的过程，是业务和技术管理过程的重要组成部分。本文通过实际的产品案例（业务运维支撑系统建设），以理论指导实践，通过进行风险与机会的管理，把现实维度及趋势维度的风险进行了提前识别，把趋势维度中的机会同样也识别出来。然后，按照四象限原则进行整合，把相应的风险转化为了机会，并把机会进行了监控，最终得到了收益。

CC-以工具提高生产力

目的  对各个业务系统环境（开发、测试、集成、验收）的高效响应  提高各环节的生产率及准确率  弥补业务参数研发的资源短板（以工具代替研发人员）  非业务参数配置中心人员也可以随意部署、升级  升级通用化、标准化（随着版本的增加，不需要新增、修改升级代码）

K8S学习笔记（分类整理以及一些思考）

1：关注Master及workNode上都有什么组件 2：为什么Kubernetes会设计出一个全新的Pod概念并且Pod有这样特殊的组成结构 3：Service的多端口问题 4：Service的外网访问问题 5：决定何时在pod 中使用多个容器

RocketMq源码学习过程中的总结资料

1：Mq的ConsumerMode模式 2：相关名词 3：rocketmq怎么保证队列完全顺序消费 4：消费速度慢的处理方式 5：Broker线程模型 6：Rocket MQ 消息过滤是发生在服务端还是客户端？ 7：为什么基于表达式 tag 会在客户端再进行一次过滤 8：Rocketmq中的单向（oneWay）机制

web请求中带参数相关56个案例分享

基于web技术经常设计到的请求类型GET、POST、PUT、DELETE等案例，以及涉及到Spring框架的使用方式，参数接收异常场景；底层Servlet技术

锻造一支听指挥、打胜仗、风气正的项目的团队

锻造打胜仗技能 “打胜仗”是团队的核心目标，更是团队的根本职能和团队建设的根本指向。反映在项目团队中拼的就是技能、业务、规范。 注入迭代思维 凡是过往都能教会我们成长，组织项目团队不定期的进行“三看“：从上往下看，从外向内看，从前往后看。就是要跳出来，用上帝视角，以更广阔的视野和相当的前瞻性去看每个项目成员、每个项目的当前形态。这种”回看“就会形成”横看成岭侧成峰，远近高低各不同“的景象，从而避免成员及项目一直在原地打转转，只是紧盯着现在的项目、产品。那整个团队所处理的事情就两个特点：简单和简单的重复。通过”三看“这种方式，使团队成员通过处理不断的冲突、冲击而促使个人及项目进行迭代、演化前进。 统一价值观 “听指挥”是团队建设的根本方向，必须贯彻执行公司、部门分解下来的工作任务。无论做项目还是产品，你的价值观决定了你会做成一个什么样的产品。所以，在团队里，每个季度都会召开正式或者非正式的组织生活会，进行团队的价值观的盘点。一直把“团队明天会面临什么？”这个问题让组员铭记，不要放松、更不要躺平。

向内求缓解多版本并行问题

年终总结时，与团队成员一起回顾了一年的工作，全年支撑生产业务58个版本，完成了业务及技术上所提需求。但就像《置身事内：中国政府与经济发展》这本书中写道：站在岸边只看到波澜壮阔，看不见暗潮汹涌。只有置身事内，我们才会有很深刻的体会。考虑团队项目特点、疫情、HW、重大节日保障等因素，每个团队成员都有同样的感受：版本并行太多，版本先后顺序调整太频繁，内耗徒增厉害。 山本耀司曾说：“自己”这个东西是看不见的，撞上些别的什么，反弹回来，才会了解“自己”。跟很强的东西，可怕的东西相碰撞，然后才知道“自己”是什么，这才是自我。恰好团队中的项目22年在外部因素以及自身项目特点的碰撞下，多版本并行所折射出的问题尤为明显。在团队成员思想碰撞下（内部充分研讨，建立从上到下的全局观，深耕自身能力），经过向内求的方式寻找到一些方法来化解此风险，同时也识别到了一些机会。

记业务参数配置中心系统建设

现阶段虽然已经实现了参数管理的相关生态建设，同时参数配置中心也在当作产品已对外输出（已输出到商品指数、场外服务）。但随着对参数运营认知理解的加深以及数字化转型的迫切需要，参数配置中心正通过破界+组合创新的手段，朝着参数运营生态圈进行建设。 研发流程上：我们基于公司规范，不断完善适合自己的研发流程，动态调整研发流程节点梳理、节点实时方案等；开发工具上：研发开发配置工具、配置检查工具，降低人工引入缺陷的风险；测试质量上：自研自动化接口测试工具、复杂场景配置工具、按参数类别整理不同测试流程、测试模板等；应急处理上：我们对于重点业务定时提前巡检，有问题能提前暴露、实现应急程序，以备紧急关头使用. 当走过足够远的路，你会发现，很多事并不是因为美好才开始，而是因为走下去，改变了，才看见了美好。

注册中心选型方案（含POC介绍）

现有业务系统中有一些公共的、基础的数据是多个系统都需要的，而这些基础数据的来源比较分散，依赖也比较混乱。为解决这些通点，后续采用服务化的机制。服务化后最核心的为服务治理，就会涉及到注册中心、负载均衡、配置中心等组件框架。 含POC，部署介绍

重构思路浅谈（最后一根稻草型时机）

此重构准备是一个不断循环的过程。 识别：发现已有系统哪些设计背离了整体的架构设计或者扩展性不强； 论证：对识别出的问题进行重构设计，需要反复论证、预研； 归类：哪些重构点可以综合在一起考虑去设计，有利于架构的完整性、统一性； 优先级：重构不能一步到位，梳理出依赖关系，在不同的迭代中进行重构； 过滤：包含很多方面。比如：重构方案若是涉及到新的技术、框架，学习门槛很高，那就要结合项目团队的技能情况进行评估，适当的过滤。再比如，基于重构所带来的收益考虑，是否值得，就需要商榷了。