文档介绍：传统IT（架构、开发、运维）岗位面临的挑战与应对之策
       
 
 
 
 
 
 
 
     
     
     
 
 
 
近几年，在IT软件领域随着云计算、微服务、容器、云原生、devops等一系列新技术、新思路的出现；“IT驱动业务”、“IT引领业务”这些理念的普及；以及以BATJ为首的互联网公司在一些活动上的宣传，对传统行业的IT部门还是造成了一定的影响，传统行业的IT部不同岗位人员应该面对这样的变化，应该如何调整应对呢？本文将从架构岗、开发岗和运维岗三个岗位对此问题做一些分享和讨论。
首先我们谈下架构岗。架构岗面临的问题主要有以下几个方面：
一是传统的基础架构向云化基础架构的转变。以前传统架构下，基于系统建设和硬件设备都是集中式的思路，架构师的思路也更多的是考虑的是系统建设和设备的纵向扩容能力，就导致单体应用越做越大，包含的功能越来越多，做一个微调都会“伤筋动骨”，硬件选型的思路也是看重单个设备的性能、稳定性以及纵向扩容能力。但是我们都知道“云计算”的资源池是以稳定性远远低于小型机的x86服务器为主，并且强调的是横向的扩容能力。“稳定性差”和“横向扩容”这两点就和原来的思维发生了直接180度的冲突，该怎么办呢？首先就要先搞清楚“云”是分层的，一般经典的分法是iaas/paas/saas层，并且是一种按需分配资源的服务化理念，既然是服务，就首先要看清楚自己的服务对象是谁，然后针对不同的对象设计不同的架构方案。例如，针对iaas层他的服务对象主要是运维人员和开发人员，那么在设计iaas层的架构的时候，作为架构师就要抓住这两类角色的不同需求，运维人员更关注的是如何能提供稳定、高效的计算和存储服务，能否支持热扩容，能够知道分配出的资源使用是否合理，能否支持同城双活和异地灾备；开发人员关注的是iaas层能否提供快速甚至是自助式的计算资源交付，如果出现灾难，能否快速的恢复我的应用等。同时，尤其是在今年疫情期间，移动办公和统一桌面云也越来越受到重视，这在传统企业的传统岗位上以前是没有的，现在作为架构师，就要考虑为了支持这样需求，在架构层面需要做哪些调整（网络接入、带宽、限流、身份认证、链路加密、数据防泄漏、后续扩容等）。
二是容器化技术。容器作为这几年的IT界热词，尤其是K8S统一江湖后，你出门不和别人谈K8S、容器，就会被感觉是落后了一个时代。那么在引入容器化技术后，容器要部署在物理机上还是虚拟机上，容器是单独部署一个网段还是和原来的网段共用，哪些应用适合部署在容器上，引入容器后对整个开发和运维模式有什么挑战，这些都是需要架构师去考虑的。在笔者看来，在引入容器技术的初期，应该优先在一些非核心应用的开发、测试环境上运行，一方面让开发和运维同事熟悉容器场景下开发、测试和基于虚拟机时整个流程的不同，另一方面是通过在开发测试环境运行来验证容器平台自身的稳定性，通过这两方面来评估何时部署生产环境，以及是否将重要的系统部署到容器环境。同时，对于大多数应用场景而言，其实容器运行在虚拟机上和运行在物理机上差别不大，但是容器运行的宿主机最好有单独的网段，这样有利于网络策略的配置和问题的快速定位。
三是去IOE。这是一个老生常谈的问题，现在不仅仅是要从技术角度考虑而且随着中美关系的恶化，美国在科技领域对中国