2021 年一眨眼就过去了，还没来得及写些什么就结束了。这篇总结在12月初就开始写，每日写一小部分，到12月底写完。总结是一个复杂的过程，工作中的复杂由于有周报就简单些，而生活中缺乏了积累，生活中则没有长进。生活也需要严肃对待。与其上班时认真扮演，下班后打回原型。不如下班后的生活认真一点，工作中则更佳从容。明年开始我会和夫人通过“家庭 OKR”经营家庭，并用“个人OKR”经营自己。
按照往年惯例，今年还是就工作，写作，阅读，开源软件和工具四个部分分别汇报。
去年总结了自己专注的五个关键词：咨询、敏捷和DevOps、架构、云计算 和 数字化转型。总结成一句话：
为企业数字化转型提供敏捷软件开发和云原生架构咨询。
今年的工作基本上围绕这句话展开。今年实践的内容较少，更多是交流，了解和理解各个行业客户所面对的问题。
1-4 月把去年在华为实践的领域驱动设计的架构方法论进行了沉淀。把基于TOGAF的企业架构、领域驱动设计(DDD)和规模化敏捷(SAFe)进行了结合形成了一套可落地的方法论。“可落地”的意思是这个方法论的各部分在不同的客户和项目上我都实践过，但没有完整的从头到尾实践一遍。2022年希望有机会能够完整的实践一遍并形成完整的方法体系。
我并不愿意从头创造一些新的东西(特别是方法论的轮子)，而是在成熟的方法论的基础上把实践中有效的东西结合起来，增加一些落地的原则和注意事项。并在反复应用中不断通过借鉴和实践改进。
今年第一个正式的项目，是给一个国企做数字化转型规划进行应用和数据架构的评估和分析，这个项目从5月开始持续到了9月。由于是规划项目，产出的是未来五年的建设规划，并没有落地，主要还是把架构间的关系介绍给客户。最大的收获是慢慢看到了整个国家数字化转型的样貌和逻辑。理解了什么是数字化转型，为什么要做数字化转型，答案我会放到 2022 年的博客里。
对于“数字化转型”，包括“产业数字化”和“数字产业化”两个部分，分别代表个不同目的和原理的数字化转型思路：
- “产业数字化”是借由“云大物智移”通过数据分析技术提升整个企业在其所在生态中的敏捷性，核心在于优化。
- “数字产业化”则是通过创新产生“信息服务”和“知识产权”从而形成新的业务模式，核心在于创新。
除此之外，每个企业对“数字化转型”的认识和诉求是不同的，阻力也不同，因此需要按不同的组织上下文、产业上下文和技术上下文分别对待。这些内容，有望出现在明年的博客里。
这是今年的第二个正式项目，这个项目从7月背景某客户的私有云规划。客户 CIO 认为云原生平台代表“先进的生产工具”，而基于“先进的生产工具”则会有“先进的生产技术”，这个技术就是基于云原生技术的 DevOps。
云原生会因为提升了应用的可维护性，给运维人员带来便利性的同时，也会给运维组织和运维人员带来了新的挑战。一方面是传统运维工作的边缘化，另一方面是产品的责任边界和现有组织结构带来的 DevOps 挑战。
这是企业落地云原生技术的首要问题，组织问题背后则是利益的重新划分的问题，而 DevOps 就是直面这个问题的。这也就是企业内部启动 DevOps 艰难的原因。
2019年在 GitChat 上开过一个 DevOps 的专栏，后来因为内容过时的原因下架了。2022 年我将结合最近的心得重新整理这个系列的文章，更新一些过时的内容，加入一些新的案例。
应用改造上云则是年底的新项目，早在 2018 年我就写下公有云(AWS)上的生产环境架构优化案例和迁移套路总结，当时只是一个简单的公有云应用。而今年碰到的都是私有云下的应用，很多都是客户的核心业务系统 Rehosting，这样的应用很难有像公有云上标准化的方案，特别是基础设施方案。更多的则是伴随着技术债务的遗留系统，涉及到不同的供应商和系统集成，方案更加多样和复杂，难度也更高。这方面的经验也会不断的充实，会逐步的整理成体系。
今年用于写作的时间并不多。一方面是在腾讯的工作时间更长，另一方面则是投入了更多的时间阅读。今年没有更新公众号和博客的另一个原因就是翻译了一本新书。关于工程师元技能的，这本书很棒，给我的工作方式带来了新的启示。目前这本书的第一遍编辑已经结束，我在进行修改。顺利的话明年下半年可以出版。
但是，我去年和陈晓鹏老师合著的新书却没有在今年出版，目前这本书的最后一章还正在编辑。最后一遍编辑过的话，就能拿到书号。顺利的话明年年终就能出版。
公众号断更了一年，关于公众号的运营，会放到明年的 OKR 里，内容和博客保持一致，同时各内容平台的“博客搬家”功能也会统一调整。
今年读的书一方面是由于工作的需要，另一方面则是发现自己的写作水平不如从前了。今年所以今年多读了一些书，除了工作相关的数字化转型和架构以外，还涉及了哲学**和。还有一些传记、小说和治愈类读物。
做数字化转型的关键在于客户是如何认识数字化转型的，特别是上半年几本上客户都在讨论“中台”。而大部分则认为这是一种技术变革，没考虑到康威定律带来的组织结构调整。当你的企业越来越依赖信息化的手段进行数字化的时候，康威定律的作用就越发的强大。
架构的书要反复读，因为架构更多是一种“不可言说的知识”，需要亲自实践体会。否则就会变成一种形而上学 —— 脱离实际的约束的空想。关于架构的 How 的书籍很多，但是关于架构 Why 和 What 的问题较少一点。此外，当前关于架构的书很少考虑到架构中“人”的因素。我写的这些文章会关注到人在做架构这件事的人的因素。
去年疫情在家的时候读完了《禅与摩托车维修艺术》，这既不是一本讲禅的书，也不是一本讲摩托车维修的书，更不是一本艺术的书。那时的我仅仅理解仅仅停留于旅游和哲学思辨的部分。缺失了对禅本身的认识，今年又顺着那个时代影响较大和禅相关的作品继续阅读。禅对那个时代的美国的年轻人产生了很大的影响。而今年了解完禅之后，发现《禅与摩托车维修艺术》是作者在实践“禅”的记录。
关于什么是禅，自己的理解：禅是一种哲学思想，需要人抛弃理性和对概念的迷恋，而专注于个人实践中的体验。而不同个人体验的过程和结果之前又有抽象的一致性，这种一致性就是“禅”。引用铃木大拙在《禅与日本文化》中的一句话就是：“禅并不是必须无视语言，而只是充分意识到，它们总是容易使自己脱离现实，沉溺于概念当中；而这种概念化正是禅所反对的。”而这一概念也贯穿了我上述所提及的所有作品。
开源软件和工具
Provisioners : 今年一直在学习 K8S，因此做了一个 K8S 一键搭建的解决方案，包括我在学习过程中的脚本集合。包括以下几个功能：
- 支持 ubuntu/centos 两种 Linux 作为控制面和节点系统。
- 支持指定 K8S 版本。
- 支持指定 K8S 安装包和镜像来源(阿里云镜像源和 Google)。
- 支持工作节点自动加入控制面。
- 支持 Flannel 和 Calico 两种 Pod 网络插件。
- 默认安装 Helm 3。
不得不说，在自己家里搭建一套 K8S 集群真的太难了！
Guides : 采用 Mkdocs 构建的个人知识库，目的是为了能够沉淀可以复用的知识。和博客不同，博客的目的在于分享当时的想法，未来不会更新，写作风格也偏个人口语化。而知识库则用于知识的积累，会不断更新，且写作风格更加书面化。内容包括：
- 企业架构
- 敏捷软件开发
- DevOps
- 云计算(AWS，Azure，腾讯)
- 编程语言(Java，Python，JavaScript)
- 基础知识(网络、Linux)
未来随着我的知识和经验的积累，知识库的内容会及时更新，频率会高于博客。
明年的计划
明年会和夫人采用 OKR 来经营家庭和个人，并且以月为单位进行 OKR 的复盘实践。关于明年做什么，元旦后会通过 OKR 的方式呈现。
新年快乐！
原文链接：https://blog.csdn.net/byronm/article/details/122265910?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522169258128116800213077763%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=169258128116800213077763&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-22-122265910-null-null.268%5Ev1%5Ekoosearch&utm_term=%E8%A5%BF%E5%AE%89%E6%91%A9%E6%89%98%E8%BD%A6
