Z银行自用云平台项目实施复盘
-张不断 2021年1月下旬
2020年秋冬时节，本人以技术经理（TD）的身份，主导了Z银行自用云平台项目实施，实施过程中可谓是呕心沥血、精疲力尽。一方面是客观压力迫使的无可奈何，一方面是主观不足导致的无可奈何。
以下为ORID形式的项目实施复盘。
1.Objective客观事实
*交付时间
2020年10月9日开始，原计划11月底收尾，最终延期到2021年1月下旬。
*参与人员
项目经理PM、技术经理TD、ASP工程师（3人->1人）、驻场工程师（2人），网络项目组，客户接口团队，集成商系统团队。
*项目规模
3个Region，共计25个AZ，12套分布式块存储，总计584台物理服务器。
1套独立部署的对象存储，总计8台物理服务器。
*现场情况
远程交付：设备环境在内蒙古呼和浩特，办公地点在北京。
现场操作区是客户信息运营中心，信息管控严，笔记本电脑不能携带进场，研发无法远程访问客户环境。
*涉及到的产品和技术
HCS6.5.1 Type2，ARM架构&x86架构，块存储FusionStorage8.0.1/6.3.0，融合ELB服务，CSDR容灾服务，IPv6/IPv4&IPv6双栈改造，SPC6&SPH7布丁改造，OVS端口镜像，第三方云管平台，对象存储OceanStor 100D 8.0.3。
2.Reflective情绪感受
时间紧、压力大、变更难、问题杂、周期长，交付过程举步维艰，令人身心疲惫。
*时间紧
按客户要求，10月22日生产内网具备对外提供云主机的能力；10月31日联通生产DMZ具备对外提供云主机的能力；11月要完成联通其他AZ的总体扩容。12月中旬电信生产内网备对外提供云主机的能力；12月下旬完成电信其他AZ的总体扩容；还有各种业务上线保障……交付现场一直是与时间赛跑。
*压力大
整个10月和11月，每时每刻客户团队都有人（接口负责任或实习生）在操作现场监督（兼学习）我方工作；现场每一个问题客户都会查根问底，部分阻滞时间较长的问题会被放大、引起恐慌。现场交付团队压力非常大。
*变更难
现场是远程交付，云平台属于开局新搭建，但网络是生产环境，所有网络配置均需要提操作变更，并且变更操作只能在晚上21:00之后。这造成现场配置和调测的试错成本高、阻滞时间长。
*问题杂
由于规模大、场景复杂，平台部署过程中出现非常多问题，其中相当一部分由产品缺陷或不足引发的。此类问题过于复杂，在加上研发远程支撑效率低，问题定位和处理耗时甚长。
*周期长
自用云平台交付期间，交付人员同时承担已投产的专项云平台的大量变更；另外，客户侧申请容灾链路长时间受阻，致使电信生产内网部署延期近一个月。项目整体交付周期被极大拉长。
3.Interpretive反思启发
本次项目交付，总体上客户表示满意。但实施过程，无论是交付组内部，还是交付组与客户团队之间，都存在不少问题和矛盾。
*现场人力资源不足
ASP人员能力不足——前期平台安装，要求人员问题处理能力强；ASP的华为云工作经验平均不到半年，难于处理问题。
ASP人员变动频繁——后期业务配置，要求人员现场环境熟悉度高；交付人员变动频繁，驻场人员更迭，现场瓶颈很明显。
*现场责任界面不清晰
责任范围难以落实——ASP人员轮班导致无法一人紧盯一套环境；ASP总体是学习心态、在现场缺乏方向感。
能力梯队没有形成——ASP能力不足，现场问题在客户的监视下均需紧急处理，结果绝大部分都堵在TD身上。
现场管理没抓到位——TD一直处于救火状态，现场人员管理和沟通管理方面没有做到位。
*研发远程支撑困难
现场环境封闭——研发无法远程访问现网环境；现网错误日志往外传平均需要用时一天；问题定位分析主要通过拍照。
沟通不畅顺——ASP无WeLink账号、缺华为邮箱账号，与研发沟通存在障碍；深夜实施，联系研发更是难上加难。
*客户侧需求变化大
接口负责任更换——原接口负责人因伤退离实施现场；新接口负责人技术水平较低、无经验、怕出事。
业务上线无规划——客户侧无明确的资源分配规划，哪个业务部门喊声大，就紧急响应哪块业务的需求。
新老项目并行走——现场是自用云平台交付与专项云平台维护并行，交付人员的工作范围严重蔓延。
4.Desisional决定行动
当前项目实施是一期建设，后续还有二期、三期建设。需要做好当前项目的善后工作，并引以为鉴。
当前项目善后工作：
*产品问题收编
针对项目中出现的主要问题，拉产品线研发对其，推动修改、优化。
*实施方案完善
针对项目实施过程中的手工操作步骤、非标做法，刷新实施方案。
未来项目优化工作
*严抓准备工作
准备工作要覆盖到位、准确完成，慎防非一致性成本。
*严抓项目管理
稳定团队，落实责任，及时总结调整；管理客户期望，引导客户需求。
网友评论