楔子
IT行业的从业人员，似乎有一个永远难迈的坎——35岁。35岁之前你可以在职场傲娇任性、肆意折腾，35岁之后，突然就得如履薄冰、夹着尾巴做人，生怕哪天被公司扫地出门、被更年轻、“性价比更高”的后浪拍死在沙滩上。
其实，这既是一个真命题，也是一个伪命题。若单纯突出低层次编码开发能力（俗称码农），忽视了技术的深度积累、业务的持续沉淀，这确实会存在“年老色衰”的风险。但如果能在特定技术领域做持续深入钻研与积累，突破架构师、技术专家的层层境界，则会越老越吃香。而如果能在此技术积累基础上，叠加特定业务领域的长期沉淀，则能进入另一层境界——领域解决方案专家，你就能“凤凰涅槃，越老越吃香”。
一、何为真正的领域解决方案专家
在当今移动互联网的下半场、云原生的上半场，全社会行业经过互联网技术的洗礼，不论前端还是后端，纯IT技术的稀缺性优势越来越小，各行各业急缺的都是能将IT技术能力融合自身业务的方案落地能力，若能最终形成某一领域的整体产品级解决方案甚至能一跃成为行业龙头，这类人才才是当今最稀缺的精英级资源，这有一个专业称谓——某某领域解决方案专家。
当前，这个名词在IT服务提供商中出现得比较多，一般是指售前部门中的行业领域解决方案专家。不过这毕竟仅仅是乙方角度，终究不能长期深入企业的具体业务运作，整体能力层次还是偏浅的。如果真要从甲方角度出发，乃至站在数字化转型的高度来定义，这类人才既需要有一定年限（至少5年，如果要掌握云原生技术体系，时间更长）的IT技术积累，也需要在特定业务领域经过较长时间（至少3~5年）的从业沉淀。除了最基础的编码开发、产品设计或系统测试能力，更要能长期深度参与特定业务领域的技术方案落地与持续产品化运营，再进一步融合转化成具备一定专业深度的领域产品级解决方案的规划设计能力，而这显然是需要依托长期的业务浸营、并有持续的互联网产品思维锤炼，才可能有的能力质变。不夸张的说，不下十数年积累，无法得其道。
这类高端复合型人才，是很依赖成体系的IT技术积累而进化出的方案悟性的（本文自然也只能算是师傅领进门，修行还得靠个人）。
当然这类人才在全社会行业都还属于新兴物种，虽然也有所谓“π型”人才的提法，但是怎么成批次培养出来，其实都是莫衷一是的。于是，便有了本文产生的价值。
二、领域解决方案专家的价值
对于大部分IT从业人员而言，年纪渐长，一方面意味着技术能力的稳定与经验累积的成熟，但也往往意味着认知边界的固化、思维模式的僵化，进而容易陷入局部经验主义的自以为是的“迷之自信”盲圈。从笔者多年的工作经历来看，此类现象不论传统行业还是互联网行业，均很常见——因为在当下，IT类工作分工越来越细，每个人都只是企业庞大运作体系下的一颗螺丝钉，自然很少能有全局视角来看问题与解决问题的能力与机会。
掰个小栗子：以笔者最近有幸组织并参与的一次核心交易系统的压力测试为例，在与多位资深后端开发同事以及运维同事的协作过程中，便深为其扰——在就某些压测场景的具体诉求尚未表述完成前，对方便已经自以为懂的把所谓“答案”脱口而出了，因其并没能完全获知笔者信息并理解笔者意图，其所谓“回答”自然是谬之千里。
此类问题，深究其原因还是在于缺乏解决方案专家级别要求的产品化交付思维，一方面在于其虽然处于IT专业岗位多年，但是囿于当下的组织分工，对IT知识体系缺乏系统化认知，故而对问题的判断仅能依据其经验来“管中窥豹”，缺少基于IT技术体系化积累形成的全局方案洞察力，再加上还少了一份基于全局认知的审慎责任心态，自然更达不到“一叶知秋”的方案高度要求；另一方面在于传统行业中，业务与IT长期分离并行运作，IT之于业务只是“幕后”的支撑角色，而不是协作甚至引领角色，IT人员对业务缺乏长期的深入浸营以及面客经验，自然就缺乏谨言慎行的责任意识与风险把控能力，反而由于长期定岗变得麻木无知却又盲目自信。
此类情况对于所有企业来说都是百害而无一利的，在金融行业尤为致命。轻则使各研发岗位能力提升陷于停滞，使企业整体IT技术能力长期在低水平徘徊；重则会导致生产系统缺乏交付质量与落地可信度，频繁因各类IT系统问题引发客诉事件，使公司业务经常陷于刀山火海之危险境地。
而基于云原生三驾马车进行的企业数字化转型，在当下看来，虽不能药到病除，但至少是一剂可预见的“治本良方”。
上述问题，究其本质，还是因为——虽然信息科技的发展已经从Web1.0时代（满足从0到1的信息化建设“温饱述求”）进入到移动互联网时代（产品为王，需满足从10到100的整体服务体验述求），企业研发组织机制却没能及时跟上并升级（哪怕现在都已经进入移动互联网下半场了）。企业没能及时提供产研运一体化的研发团队运作机制土壤，打造业务IT一体的“团队熔炉”，使这一批人错过了能力进化的机会与时间窗。
其实，这群人一旦能从此混沌意识中破茧而出，职业前景与能力提升空间都还是非常可观的（毕竟这么多年的专业积累还在那，也有一定的业务认知）——如果将其往领域性解决方案专家方向培养，则退可以成为业务需求分析师（甚至高阶的业务型产品经理）或IT技术专家，进可以独领一个业务线或领域的产研团队，甚至引领公司某一业务/技术领域的行业方向发展。对于公司而言，人员能力水涨船高，组织活力重新迸发，业务增收自然是水到渠成之事。
三、云原生时代对领域解决方案专家的时代机遇
在云计算到来以前，计算机行业的高校人才培养，虽然其课程设计算得上是成体系的，但是一直是重理论轻实践（也有部分原因是IT技术迭代太快，高校老教授们技能更新跟不上）——缺少软硬一体的全栈IT基础实践环境，来将系统化的理论知识转变成环环相扣地实操演练，从而无法使学生将所学计算机学科理论知识转变为体系化的技术方案认知与实操能力掌握。毕竟其高昂的建设成本、复杂的持续维护能力要求，对各大高校的计算机学院而言，都是不敢想象的。
而到了就业企业，虽然软硬件IT设施环境很完备，但限于信息安全管控要求、人才分工精细化隔离化的现实情况，IT从业人员的工作边界与认知边界依然被局限在所设岗位的“小圈圈”里，自然也极少能主动破圈思考、并做相应方面的能力提升。
但是云计算时代的来临，有赖大规模公有云的成功推广，特别是基于容器技术发展而来的第三代云计算技术（即云原生技术体系）已开始深入各行各业，高校计算机学科教育，已然可以基于更成体系、更低成本的公有云环境进行软硬一体的实践教学。而对企业而言，除了IT人员可以在云上进行IaaS、PaaS、SaaS层的体系化培训与实践，基于系统上云、系统微服务改造或容器化改造所需的全栈技能要求，也能倒逼信息技术部门尽快建立起软硬一体的全栈技术培养体系，培养或吸纳对云原生有体系化技术认知的全栈型人才。以便在如此复杂的云环境中，对IT从业人员有全方位的能力诊断，对各类技术方案能有较准确的层次水准定位——以云原生技术体系为标尺来进行人才能力水平判别，以云原生产品能力模型来对系统落地方案进行全面评估衡量。此为第一个时代机遇——软硬一体的云原生全栈技术体系的建立已具备环境基础。
第二，组织土壤述求。在第一篇中笔者已经反复提及，云原生是有三驾马车的，除了偏技术的容器、微服务，还有偏研发流程与组织保障的DevOps。DevOps便是IT从业人员能充分浸入业务、汲取业务领域专业积累、与业务人员“教学相长”的组织保障。
众所周知，如果要基于DevOps的产研运流程实施敏捷化的产品迭代运作，业务与IT必须是要组成一个产品级项目团队一体化运作的。有赖此项团队运作要求的实现，方能使业务与IT协力向前，而不是陷入互相掐架的低层次尴尬对立境地。
而如果从企业数字化转型进程来看，长期与IT团队“结对工作”，能使业务人员逐步建立IT技术的具象化认知，有利于数字化转型思维的建立以及基础IT能力的培养；另一方面，从IT人才的批量化业务能力培养角度来说，此方式是能让IT人员长期深入浸营业务的唯一有效的组织机制保障。
当然，对于企业数字化转型而言，研发组织与流程的转变往往是最难的，会动到太多人的奶酪，因此，若能先晓谕其所能，推动起来兴许也能少一些阻碍。
再进一步，数字化研发组织与流程的转型，从笔者调研来看，也不一定非得将现有企业组织架构推倒重来，毕竟传统各行各业发展了这么多年，企业组织架构的形成必然有其适应市场竞争的存在合理性，特别对于金融行业而言，还有监管的合规刚性要求。基于此背景，便有了笔者在第一篇篇尾所提及的——“人事分离“、以“事”聚“人”的组织转型解决思路。
部门依然是职能化设计，侧重专业人才的技能培养、人员招聘，基于业务产品线来建立跨部门的产研运一体化研发团队（即麦肯锡在《券商数字化转型》中所提及的”跨部门实体敏捷部落“），最终形成”井字形“组织矩阵，一举打破部门墙，在双向制衡的管理模式下，形成”业务IT抱团往前奔“的企业赛马场，而这个Product Owner或者附近的位置就应该是领域解决方案专家该处的位置。
四、One More Thing
基于DevOps体系的业务IT一体化运作模式，对于各IT专业岗位而言——不论是开发岗、产品岗、设计岗、测试岗、运维/运营岗——其业务领域积累的机会都是均等的。当然，想要从业务方案或技术方案“质变”为产品级落地解决方案，产品岗、设计岗与前端开发岗有些许分工优势，毕竟接触用户层功能的机会最多，更有机会“以终为始”地融入用户产品思维来进行领域级产品的功能规划与思考，但是也不能一概而论，只要有足够强的用户服务意识、注重产品思维的培养，各岗位的提升空间都是一样大的。
当然，从笔者这些年从业的经历与观察来看，后台开发岗与运维岗比较容易陷入工具化思维定势，从用户侧角度考虑得相对少一些，当然这也情有可原——毕竟不直接接触用户，产品感知度自然更弱。但如果确实想往领域解决方案专家方向发展，还是建议尽早从工具化思维中“涅槃重生”，尽可能地站在产品落地角度思考解决方案，终究能达到预期——“只要有一颗装着用户的心，就必能锤炼出产品解决方案之能”。
《重识云原生系列》专题索引：
- 第一章——不谋全局不足以谋一域
- 第二章计算第1节——计算虚拟化技术总述
- 第二章计算第2节——主流虚拟化技术之VMare ESXi
- 第二章计算第3节——主流虚拟化技术之Xen
- 第二章计算第4节——主流虚拟化技术之KVM
- 第二章计算第5节——商用云主机方案
- 第二章计算第6节——裸金属方案
- 第三章云存储第1节——分布式云存储总述
- 第三章云存储第2节——SPDK方案综述
- 第三章云存储第3节——Ceph统一存储方案
- 第三章云存储第4节——OpenStack Swift 对象存储方案
- 第三章云存储第5节——商用分布式云存储方案
- 第四章云网络第一节——云网络技术发展简述
- 第四章云网络4.2节——相关基础知识准备
- 第四章云网络4.3节——重要网络协议
- 第四章云网络4.3.1节——路由技术简述
- 第四章云网络4.3.2节——VLAN技术
- 第四章云网络4.3.3节——RIP协议
- 第四章云网络4.3.4节——OSPF协议
- 第四章云网络4.3.5节——EIGRP协议
- 第四章云网络4.3.6节——IS-IS协议
- 第四章云网络4.3.7节——BGP协议
- 第四章云网络4.3.7.2节——BGP协议概述
- 第四章云网络4.3.7.3节——BGP协议实现原理
- 第四章云网络4.3.7.4节——高级特性
- 第四章云网络4.3.7.5节——实操
- 第四章云网络4.3.7.6节——MP-BGP协议
- 第四章云网络4.3.8节——策略路由
- 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
- 第四章云网络4.3.10节——VXLAN技术
- 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
- 第四章云网络4.3.10.3节——VXLAN隧道机制
- 第四章云网络4.3.10.4节——VXLAN报文转发过程
- 第四章云网络4.3.10.5节——VXlan组网架构
- 第四章云网络4.3.10.6节——VXLAN应用部署方案
- 第四章云网络4.4节——Spine-Leaf网络架构
- 第四章云网络4.5节——大二层网络
- 第四章云网络4.6节——Underlay 和 Overlay概念
- 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
- 第四章云网络4.7.2节——virtio网络半虚拟化简介
- 第四章云网络4.7.3节——Vhost-net方案
- 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
- 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
- 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
- 第四章云网络4.7.8节——SR-IOV方案
- 第四章云网络4.7.9节——NFV
- 第四章云网络4.8.1节——SDN总述
- 第四章云网络4.8.2.1节——OpenFlow概述
- 第四章云网络4.8.2.2节——OpenFlow协议详解
- 第四章云网络4.8.2.3节——OpenFlow运行机制
- 第四章云网络4.8.3.1节——Open vSwitch简介
- 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
- 第四章云网络4.8.4节——OpenStack与SDN的集成
- 第四章云网络4.8.5节——OpenDayLight
- 第四章云网络4.8.6节——Dragonflow
- 第四章云网络4.9.1节——网络卸载加速技术综述
- 第四章云网络4.9.2节——传统网络卸载技术
- 第四章云网络4.9.3.1节——DPDK技术综述
- 第四章云网络4.9.3.2节——DPDK原理详解
- 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述
- 第四章云网络4.9.4.2节——智能网卡实现
- 第六章容器6.1.1节——容器综述
- 第六章容器6.1.2节——容器安装部署
- 第六章容器6.1.3节——Docker常用命令
- 第六章容器6.1.4节——Docker核心技术LXC
- 第六章容器6.1.5节——Docker核心技术Namespace
- 第六章容器6.1.6节—— Docker核心技术Chroot
- 第六章容器6.1.7.1节——Docker核心技术cgroups综述
- 第六章容器6.1.7.2节——cgroups原理剖析
- 第六章容器6.1.7.3节——cgroups数据结构剖析
- 第六章容器6.1.7.4节——cgroups使用
- 第六章容器6.1.8节——Docker核心技术UnionFS
- 第六章容器6.1.9节——Docker镜像技术剖析
- 第六章容器6.1.10节——DockerFile解析
- 第六章容器6.1.11节——docker-compose容器编排
- 第六章容器6.1.12节——Docker网络模型设计
- 第六章容器6.2.1节——Kubernetes概述
- 第六章容器6.2.2节——K8S架构剖析
- 第六章容器6.3.1节——K8S核心组件总述
- 第六章容器6.3.2节——API Server组件
- 第六章容器6.3.3节——Kube-Scheduler使用篇
- 第六章容器6.3.4节——etcd组件
- 第六章容器6.3.5节——Controller Manager概述
- 第六章容器6.3.6节——kubelet组件
- 第六章容器6.3.7节——命令行工具kubectl
- 第六章容器6.3.8节——kube-proxy
