技术和思维两类知识归纳整理(200622)

本周四即端午节,而由于北京疫情的原因估计要一个人在北京过端午。同时本周过完后,2020年的上半年正式结束,大家不知道有啥感觉?

而我最大的感觉就是我基本在一个大半部分时间都宅家的一个状态完成了上半年,今年上半年基本没有出差,而这次从6月初到北京的出差又刚好遇到了疫情,导致基本要7月下旬才能够返回深圳。同时整个上半年我们现场售前交流和项目机会感觉都明细不多,能够拓展成功的新客户更少。

在今年整体经济形势和大环境下,估计大部分的企业和个人日子都不会太好过。

最近有两个事不得不提下,一个就是中国移动等电信运营商提出的估计员工停薪留职自主创业,还有一个就是国家电网开始降薪。这两个大国企刚好都是我们服务过的大客户,而且在现在新基建,特别是5G和特高压下,这两个企业仍然应该是属于很优良的雇主类企业。但是从最近的一些政策我们也足够感受到大国企也面临的压力。

今年大家都看到的是类似旅游行业,线下的服务,教育培训,影院,餐饮等行业遭受巨大的打击。实际上我们看到类似房地产,银行等同样日子不好过。对于房地产,大部分企业都属于高负债运行,随时都有崩盘风险;而对于银行,最近又刚好提出让利1.5万亿,睡觉数钱的日子估计也会过去。

而对于我们自己来说,在今年经济形势下,最好的做法就是踏实做好自己的事情,不要轻易跳槽,不要乱花钱,更不要太多的参与到各类提前消费的网贷里面而无法自拔。简单点还是老人家说的,手里有粮,心中不慌。而手里的粮一个就是自己的活动现金流,一个就是自我核心技能积累。

周末我对自己最近3年到5年的博客文章重新进行了一下复盘,整体来说,主要包括了几个大类的文章。

1. 传统的SOA和ESB项目规划,私有云PaaS平台规划建设和实施

2. 围绕中台,微服务,DevOps,容器云,企业数字化转型的云原生解决方案类文章

3. 围绕思维框架逻辑的文章,包括学习,认知,问题分析解决

4. 围绕个人自我管理类的,包括日常随感,锻炼记录,个人自律,个人知识管理,管理心得等

而对于第1点,自己的第一本专著《SOA和大数据-私有云PaaS平台规划和建设》已经在走出版前的正式修订,预计很快出版,也算是我对这块知识的体系化整理。

那么剩余的两块知识就是云原生解决方案和思维两个大类。

而对于这两个大类,我在前面也列出了专门的目录规划,对于云原生解决方案目录如下:

中台和微服务架构咨询

在这块我写了大量的文章,有些是以中台建设的维度,有些是以微服务设计维度,而且还有一些是传统企业IT架构转型维度,而且文章本身形成在不同的时间段,相关的内容本身还存在重复。因此单纯就中台和微服务架构咨询这块的文章来看,整体的系统性和体系化还是比较弱。

如果重新构建这块的内容整体思路和目录结构应该调整为

1. 传统企业数字化转型背景

2. 支撑转型的关键技术趋势概述

2.1 中台概述(中台的概念,展现形式,中台的作用等)

2.2 微服务概述(微服务产生背景,微服务和SOA关系)

2.3 DevOps概述(敏捷研发,持续集成和交付,自动化测试等)

2.4 面向云原生的整体解决方案

3. 中台咨询和规划建设总述

3.1 中台规划咨询整体方法论(业务建模流程分析,业务中台和数据中台建设,技术中台,实施)

3.2 业务中台建设方法论

3.3 数据中台建设方法论

3.4 技术中台建设(API网关和能力开放平台,技术服务中台,DevOps支撑平台,容器云平台)

3.5 实施方法论 (实施策略,演进路线,遗留系统迁移等)

3.6 运维和管控治理方法论

3.7 技术标准规范体系 (标准规范,开源组件,开发框架等)

基于以上整个目录结构可以看到中台规划咨询的内容可以梳理清楚。对于其中的中台规划咨询整体方法论实际上可以看到是我们传统的企业架构规划咨询方法的一次大变形和大优化。 对于哪些地方出现大优化,我们准备还要单独写一篇文章来进行说明

到了业务中台,要注意到实际上业务中台本身就是由多个高度独立自治的微服务组成的,因此业务中台重点就是微服务模块划分和定义,在微服务模块划分清楚后本身又涉及到两个关键的事情,其一是该模块的数据建模,究竟Owner哪些数据对象和数据表,其二是接口服务识别和定义,究竟需要暴露哪些API接口服务能力。而对于我们经常说的这个微服务模块本身提供哪些具体的业务功能明细反而是偏内部一点的事情了。

微服务架构设计和开发

这块实际上我博客文章里面的另外一个主要内容,但是相对来说这块的内容重点还是放在了API网关方面,而其它内容比较少。实际上对于微服务架构设计开发,包括了两个方面的内容,一个就是微服务开发框架的选型和集成,另外一个就是实际的组件化开发方法流程(其中包括接口设计和开发)。还有一个内容就是我们说的当前主流的微服务支撑平台说明。

因此,对于这块的文章重新整理后整体结构更好的呈现方式为:

1. 微服务架构设计

1.1 架构设计概述

1.2 微服务组件化设计(业务架构,逻辑架构,技术架构,集成架构等)

1.3 数据库层设计

1.4 领域层设计

1.5 接口服务层设计和能力开放

2. 微服务架构当前开发框架和开源组件

2.1 SpingCLoud微服务架构开发框架

2.2 Dubbo分布式开发框架

2.3 API网关(注册,监控,安全,日志,限流熔断等)

2.4 服务注册中心

2.5 服务限流熔断

2.6 服务链监控

3. 基于微服务开发框架详细开发说明

3.1 数据库开发

3.2 业务逻辑层功能开发

3.3 接口和服务层开发(主要是围绕Http Rest接口设计开发的一套)

3.4 前端开发和前后端分离

4. 集成和测试

4.1 集成测试流程和测试方法概述

4.2 单元测试和自动化测试

4.3 集成测试和管控

4.4 持续集成和交付概述(后续应该在DevOps里面进一步详细描述)

5. 运维监控

5.1 自动化运维

5.2 资源层监控

5.3 APM和服务链监控

5.4 主流监控平台介绍和监控运维平台构建

DevOps研发运维一体化

整体从当前文章的输出来看,这块文章的内容相对来说最不系统。后续也是重点要强化的一个地方,实际上这块的内容相对多,但是我博客上文章的介绍更多的是基于我们当前自主研发的DevOps支撑平台展开的。

对于这块的内容,初步整理如下:

1. DevOps概述

1.1 DevOps发展背景和定义

1.2 云原生概述已经云原生和DevOps关系

1.3 DevOps当前开源工具集

1.4 DevOps能力成熟度模型

2. 敏捷研发过程管理

2.1 敏捷方法论

2.2 Srum敏捷研发过程管理

2.3 需求工程和用户故事

2.4 敏捷项目管理最佳实践

3. 持续集成和持续交付

3.1 持续集成方法论

3.2 持续集成主流工具链和开源组件

3.3 流水线设计(代码库,编译,构建打包,部署,交付)

3.4 持续交付和发布

3.5 资源和环境管理

4. 自动化测试

4.1 自动化测试概述

4.2 测试设计和测试数据管理

4.3 主流自动化测试工具

4.4 代码静态检查和安全性测试

4.5 单元测试

4.6 接口自动化测试

4.7 前端功能页面级的自动化测试

4.8 自动化性能测试

5. 容器云平台

5.1 容器云概述

5.2 Docker容器技术

5.3 Kubernetes容器编排和资源调度

5.5 容器云和DevOps平台集成

基于这个思路基本可以将中台+微服务+DevOps+容器云的整体面向云原生的端到端解决方案讲清楚。从这个最新的目录梳理来看,对于DevOps这块的内容我博客文章是最欠缺的,相对来说也最不系统。其次就是对于微服务架构咨询这块,虽然写过的文章很多,但是未进一步提升到比较完整的方法论,也没有一个完整的案例举例。这些可以在后续进一步完善。

对于思维类文章整理,我也给出了具体的目录框架如下:

基于我上面的构图,我们可以看到一个完整的思维范畴内容应该包括了如下展开。

1. 学习方法和模式

1.1 知识的采集方法和分析

1.2 阅读方法

1.3 学习方法和模式

1.4 POC自我验证和实践

2. 实践-》问题分析和解决

2.1 通用的问题分析解决方法论

2.2 问题分析解决

2.3 事物认知和决策

2.4 分析和模式匹配

2.5 问题解决后的呈现,演绎和泛化

3. 知识库和经验库

3.1 知识库的形成和积累

3.2 从知识库到经验库的转化

3.3 常用方法和工具

4. 总结复盘

4.1 总结复盘方法

4.2 最佳实践

4.3 归纳和抽象

从上面整个构图也可以看到,我们将学习,问题分析i解决,知识库积累,问题解决后的复盘形成一个完整的持续改进的闭环流程。再从这个闭环的流程我们可以看到。

1. 知识经验是基础,模式匹配是核心价值

2. 真正的自我能力提升一定体现在现场真正的实践上,而不是理论堆砌或POC验证

因此我们看到实践很重要,实践是你形成复盘总结的关键输入的基础,否则你拿什么复盘。理论指导实践,但是更加重要的是实践反刍理论。其次就是复盘很重要,复盘是形成和提升模式匹配能力的基础,复盘的深浅将直接决定了你跨领域的问题分析解决能力。