【摘要】近些年IT领域新技术的迭代速度惊人，加上“IT驱动业务”等理念的普及以及BATJ等互联网公司的影响，对传统行业的IT部门产生了一定冲击，传统IT架构岗、开发岗和运维岗的岗位人员面对哪些变化？又该如何应对？【作者】王洋，招商基金公司信息技术部基础架构师。硕士研究生学历，曾就职于蚂蚁金服金融云团队、商业银行、政府机关信息技术部等。擅长领域：云计算IaaS和PaaS平台规划与建设、系统架构设计、一体化运维平台建设、devops以及分布式存储，在分布式存储领域有多年实战经验，擅长根据业务特性建设分布式存储平台。持有DevOps Master认证、ITIL认证，并在IEEE Computer发表论文” on-demand security architecture”，撰写专利“一种数据保护方法、装置及数据保护系统”（专利号：201010538235.8）。2020 容器云职业技能大赛百位专家委员会成员。
近几年，在IT软件领域随着云计算、微服务、容器、云原生、devops等一系列新技术、新思路的出现，“IT驱动业务”、“IT引领业务”这些理念的普及，以及以BATJ为首的互联网公司在一些活动上的宣传，对传统行业的IT部门还是造成了一定的影响，传统行业的IT部不同岗位人员面对这样的变化，应该如何调整应对呢？本文将从架构岗、开发岗和运维岗三个岗位对此问题做一些分享和讨论。
首先我们谈下架构岗。
架构岗面临的问题主要有以下几个方面：
一是传统的基础架构向云化基础架构的转变。
以前传统架构下，基于系统建设和硬件设备都是集中式的思路，架构师的思路也更多的是考虑的是系统建设和设备的纵向扩容能力，就导致单体应用越做越大，包含的功能越来越多，做一个微调都会“伤筋动骨”，硬件选型的思路也是看重单个设备的性能、稳定性以及纵向扩容能力。但是我们都知道“云计算”的资源池是以稳定性远远低于小型机的x86服务器为主，并且强调的是横向的扩容能力。“稳定性差”和“横向扩容”这两点就和原来的思维发生了直接180度的冲突，该怎么办呢？
首先就要先搞清楚“云”是分层的，一般经典的分法是IaaS/PaaS/SaaS层，并且是一种按需分配资源的服务化理念，既然是服务，就首先要看清楚自己的服务对象是谁，然后针对不同的对象设计不同的架构方案。
例如，针对IaaS层他的服务对象主要是运维人员和开发人员，那么在设计IaaS层的架构的时候，作为架构师就要抓住这两类角色的不同需求，运维人员更关注的是如何能提供稳定、高效的计算和存储服务，能否支持热扩容，能够知道分配出的资源使用是否合理，能否支持同城双活和异地灾备；开发人员关注的是IaaS层能否提供快速甚至是自助式的计算资源交付，如果出现灾难，能否快速的恢复我的应用等。
同时，尤其是在今年疫情期间，移动办公和统一桌面云也越来越受到重视，这在传统企业的传统岗位上以前是没有的，现在作为架构师，就要考虑为了支持这样需求，在架构层面需要做哪些调整（网络接入、带宽、限流、身份认证、链路加密、数据防泄漏、后续扩容等）。
二是容器化技术。
容器作为这几年的IT界热词，尤其是K8S统一江湖后，你出门不和别人谈K8S、容器，就会被感觉是落后了一个时代。那么在引入容器化技术后，容器要部署在物理机上还是虚拟机上，容器是单独部署一个网段还是和原来的网段共用，哪些应用适合部署在容器上，引入容器后对整个开发和运维模式有什么挑战，这些都是需要架构师去考虑的。
在笔者看来，在引入容器技术的初期，应该优先在一些非核心应用的开发、测试环境上运行，一方面让开发和运维同事熟悉容器场景下开发、测试和基于虚拟机时整个流程的不同，另一方面是通过在开发测试环境运行来验证容器平台自身的稳定性，通过这两方面来评估何时部署生产环境，以及是否将重要的系统部署到容器环境。同时，对于大多数应用场景而言，其实容器运行在虚拟机上和运行在物理机上差别不大，但是容器运行的宿主机最好有单独的网段，这样有利于网络策略的配置和问题的快速定位。
三是去IOE。
这是一个老生常谈的问题，现在不仅仅是要从技术角度考虑而且随着中美关系的恶化，美国在科技领域对中国“卡脖子”越来越多，政治的角度也会加速去IOE的过程。
根据笔者的了解，在IOE中，相对而言，I（IBM）是大家去的比较快，也比较容易的，毕竟云化的基础就是x86，架构师需要评估好业务容量、重要程度以及关联影响，规划方案，分批设计迁移方案即可；再来看看O（Oracle），这个就要分行业看了，目前国内互联网公司基本都是使用MySQL了，去O的力度是最大的，但是在传统行业里，一些核心系统还是在使用Oracle，这个迁移的方案设计就是对架构师的一个挑战，主要涉及基于MySQL的高可用方案、双活方案、分库分表、读写分离等；最后来说下E（即以EMC为代表的集中式存储），这一部分，目前随着基于x86的分布式存储技术的普及，作为架构师就需要考虑使用分布式存储的可行性以及落地路径，笔者还是建议使用万能公式：“先开发测试环境”加“时间验证”再逐步向生产环境推广，最终替换集中式存储。
四是开源软件引入。
随着互联网技术在传统行业中使用的越来越多，伴随而来的是大量各种各样的开源软件被引入。这就带来了一个问题，如果架构师不能从众多的开源软件中选型出适合本公司的开源软件，而是任由各个开发团队自行引入和使用，那将带来巨大的灾难。一方面，同类型的开源软件引入多个，导致系统对接成本提升和代码复用率下降；另一方面，每引入一个新的开源软件，就需要定制其规范和使用标准以及安全需求，况且开源软件版本升级快，安全漏洞多，维护成本较大。
因此作为架构师，非常有必要根据公司的具体情况设置开源软件的可选列表，最好是每个方向（java容器、消息中间件、缓存、协调中心等）选择一个作为标准选项，如果需要引入新的中间件，则需要经过评估后才能引入。
五是应用的弹性扩容。
应用的弹性扩容，也是这几年来被讨论较多的话题，往往会被人和淘宝双十一的秒杀放在一起讨论。弹性扩容场景目前在传统行业也是有应用场景的，虽然可能达不到双十一那样的规模。例如，现在很多有电商部门的公司也会搞一搞秒杀或者大促，在秒杀或者大促的场景下应用的弹性扩容也是这个场景下非常重要的一环。
要做弹性扩容，首选的方案是要把应用的架构改造为无状态应用，这也是业内主流的做法，把应用的状态统一集中进行管理后，应用自身的扩容才能平滑进行。但是，一个实际情况是对传统行业有些应用很难做无状态的改造，那么就需要考虑在将应用扩容后，要做一个状态的同步动作，然后才能对外提供服务，这个过程时间会远大于无状态应用，所以有些场景的适应性会差一些。架构师能够根据公司的实际情况，针对不同应用设计不同的弹性扩容方案这也是一个挑战。
六是微服务设计。
微服务其实并不是一个新概念，但是这些年随着容器热度的提升，微服务也开始成为“网红”。不夸张的说，现在出去做技术分享，如果你说你们公司还没有进行微服务的建设，那么真的是会有人觉得你们公司low的。
作为一个架构师，在微服务方面，你需要知道什么样的系统适合进行微服务改造，如何使用领域模型对应用进行设计，需要知道如何对微服务进行治理，微服务的网关应该设计在什么位置上，如何避免微服务拆分过细后变成微服务“地狱”，微服务和容器到底是什么样的关系等。
七是研发一体化。
这里涉及需求管理、需求开发、测试和部署上线等环节。在传统行业中，每个环节基本上都是有存在部门墙并且是都有独立的平台在工作。那么为了加速业务需求的上线速度，让业务能更快的响应市场需求，作为架构师，就有必要打通以上提到的各个环节，建设一个公司级别的研发一体化平台。在这件事情上，就不仅仅是考验架构师的技术能力了，还会涉及到沟通能能力，人际交往能力甚至是向上管理能力。
接下来，我们谈下开发岗位面临的一些挑战。
一是敏捷开发。
传统的瀑布式开发模式由于响应周期长，已经严重的掣肘业务的发展，跟不上市场的变化。敏捷开发模式讲究的是，快速迭代，小步快跑，这就要求开发人员要对业务需求的大背景有清晰的理解，这样才不至于在做每个小迭代的时候理解错误或者增加额外的沟通；另外，敏捷开发中每个迭代都有清晰的时间点和需求清单，这就对开发人员的能力有一定要求，会提升开发人员的开发效率，一定程度上减少“划水”的时间。
二是适应云原生的开发模式。
根据笔者的了解，目前传统行业里真正搞云原生应用的还并不多，但是云原生的应用将是随着云计算落地后的必然发展途径，因此从未雨绸缪的角度来讲，开发人员了解云原生应用的开发模式也是非常有必要的，并且云原生应用中的一些开发思想也是可以对现有的工作进行指导和参考的。
三是适应devops的模式。
很多人会把devops看做一个工具，或者一个岗位，其实在笔者看来，devops是一种工作模式，是一种能把业务人员、开发人员、测试人员、运维人员联系在一起的一种工作模式。而开发人员在这里有着承上启下的作用，devops中的CI阶段，开发人员对这个阶段的理解和实践方式，其实是对整个模式的运转效果产生较大影响的。因此，在devops的流程中，CI阶段的设计往往会根据各个公司的实际情况和研发能力来进行设计，换句话讲，看一个公司devops流程中CI的设计，也能从一定程度上反映出该公司devops能力的强弱。
再者，我们聊下运维岗位面临的一些挑战。
一是基础资源从集中式向云化转变。
传统的集中式基础资源，讲求的是单体的性能和稳定性，思考问题的方式是纵向的。但是在基于分布式的云化基础设施下，运维人员需要考虑的是云资源池的故障域要如何划分、云资源池的规模要如何设计、不同环境的资源池要如何隔离、资源的超售比设置为多少、资源的标准化要如何设计、云化资源池中不同范围的故障发生后，如何保证继续提供可靠的服务，这些都是云化以后运维人员需要考虑的。
二是运维前置。
笔者发现，有些公司运维人员做的事情太过于底层，只负责OS层及以下的部分，对应用层的运维完全不懂，以致于在应用出现问题的时候，看起来都是开发在排查问题，给领导的感觉会比较差。同时，随着云计算的普及，OS层以下的内容，后续很可能直接被云服务商托管掉，就类似现在很多公司使用的托管机房，以及很多创业公司直接使用公有云，极端情况下，就可能导致运维人员下岗。
因此，运维人员应该让自己的技能前置，例如，对于java技术栈为主的公司，对于运维人员而言最好是要学习java虚拟机的相关知识和技能，这样在java程序出现问题的时候能够快速定位问题，而不是强依赖开发人员。
三是容器运维。
容器平台在被大量使用以后，一定会带来运维问题，但是容器平台的运维模式和基于虚拟机的运维模式是完全不同的，这就需要运维人员能够熟悉容器平台的运行机制，对容器有理论上的知识储备以及实际的运维能力，而这项技能对传统运维人员而言基本就是全新的领域。
四是开源软件的运维。
前文提到了架构师需要对开源软件的引入进行专业的评估和把控，那么对于引入进来的开源软件的运维工作就落到了运维人员头上。传统的公司的运维，一般都会买一些外部的运维服务，而这些运维服务大多数也都是针对传统的商用软件而不是开源软件。因此在引入开源软件以后，对于运维人员而言，原来可以依靠的外部服务没有了，自己就需要去能够具备运维开源软件的能力，这里要投入的学习成本是相当高的，并且没有一个所谓的“掌握”标准。
如何应对？怎么转型？
从架构师、开发、运维这三个角色谈了这么多以后，接下来谈下有哪些途径是可以帮助传统行业的人员进行转型呢？在笔者看来，有以下几个方面：
一是自主学习。
引用一句老话“活到老，学到老”，尤其是在IT这个新技术日新月异，层出不穷的时代，自我驱动学习是一项基本要求；
二是加入一些真正讨论和提升技术的圈子。
目前社交平台和软件有很多，但是鱼龙混杂，要不就是一些群打着技术交流的幌子，在里面进行广告推销，要不就是加入群以后根本没人说话，要不就是里面全是一些伸手党，所以想要找一个靠谱的圈子是有一定难度的，较好的方式还是通过“大牛”引荐或者可以加入以twt社区为代表的平台进行从基础到进阶的培育交流，答疑解惑。
三是在工作中，利用项目建设或者其他能接触新技术的机会，积极参与其中。
通过项目建设本身，学习涉及到的知识，并且伴随着项目落地自身对涉及到的知识也有了较好的实践。
如果你目前在传统行业的岗位上遇到了由于新技术带来的挑战，那么欢迎和我一起讨论。
