北京
公司通知你下周一去客户现场，接手上一任FDE留下的项目。前任走得很突然，没留交接文档，连代码仓库账号密码都不知道。客户技术负责人第一句话就是：你们的人走了，系统每天晚上8点就挂，你什么时候能修好？
做FDE这几年，接过不少这样的项目，前任留下的十有八九都是坑。不是技术问题，而是信息缺失、责任不清、客户不满意。接手项目的第一周，先看三个地方，就能摸清项目底细。
一、确认过往资料：三看
接手项目的第一件事不是改代码，而是确认过往资料。
看配置文件。配置文件是项目的身份证，先确认版本号、环境变量、依赖服务、密钥有没有问题。很多时候系统跑不起来，就是因为密钥过期，或者指向了客户的内网地址。有次接手项目，第一天就发现配置文件里有3个问题：数据库密钥过期、Redis地址指向测试环境、Python依赖版本和生产环境不一致。这三个问题不先解决，后面什么都做不了。
看客户修改记录。去客户的代码仓库看git log，重点看最近3个月的提交记录，看客户改过哪些文件、为什么改、改完有没有问题。再搜一下代码里的TODO、FIXME、HACK，很多坑都藏在这些注释里。有次看git log发现客户在2个月前改过一个数据同步模块，注释写着“临时方案，后续优化”，去看代码，客户把异步改成了同步，导致高峰期数据库连接数暴涨，这就是系统每天晚上8点挂的原因。如果前任FDE还能联系上，问一句“客户改过哪些东西，为什么改”，能省掉80%的踩坑时间。
看未完成工单。重点看状态是“已临时规避”的工单，问题没解决，只是用临时方案绕过去了，随时可能复发。还要看那些“已关闭”但客户评价不满意的工单，前任可能为了KPI强行关了，客户心里有怨气，你接手后可能会翻旧账。第一周给客户发一封交接确认邮件，列出所有未完成工单，让客户确认哪些是高优先级，这封邮件既是工作记录，也是保护自己的证据。
二、检查业务流程：四层检查点
确认完资料，接下来检查业务流程，找出系统的卡点，分四层看。
- 系统层看4个点：版本、环境变量、依赖服务、密钥。很多问题出在环境变量上，前任在本地改了但没同步到生产环境，你接手后系统就跑不起来。
- 数据层看3个点：数据源、权限、备份。有次接手项目，客户数据库只给了只读权限，但系统里有个功能需要写入，前任用临时方案把数据先写到本地文件再手动导入，能用，但维护成本高、容易出错。
- 业务层看3个点：客户特殊逻辑、SLA、升级路径。有次客户的SLA要求是99.9%可用性，但前任没做高可用方案，系统是单机部署。我花了2周优化准确率，客户却说“我不关心准确率，我关心系统别挂”。
- 运维层看2个点：监控告警、应急预案。有次接手项目，告警接收人还是前任的手机号，系统挂了半天客户才发现。接手后第一件事就是把接收人改成自己的手机号，再写一份应急预案。
三、准备行动方案：第一周怎么做
第一周的目标不是解决所有问题，而是识别风险、排定优先级、和客户对齐预期。
D1-D2先让系统跑起来。这两天不要急着改代码，先把配置文件、环境变量、依赖服务、密钥全部确认一遍。系统跑不起来，你什么都看不到；跑起来了，才能看到真正的问题。还是跑不起来，就找客户要账号、要权限、要文档。
D3-D4识别遗留问题。用三看原则和四层检查点把问题全部列出来，按严重度和紧急度排序：高严重度高紧急度是P0，立即修复；高严重度低紧急度是P1，排期修复；低严重度高紧急度是P2，降级处理；低严重度低紧急度是P3，记录观察。系统每天晚上8点挂这种问题属于P0，不能拖。
D5和客户对齐。发一封邮件列出这一周看到的所有问题、优先级排序、修复计划，再约客户开会当面确认优先级、交付时间、责任边界。话术可以这样：先报告系统已经跑起来了，再展示你排好的遗留问题清单，对8点挂的问题给出具体修复时间，明确需要客户配合的数据库权限和环境变量，最后约定每周一封进度邮件。
和客户对齐时，千万别说前任FDE的不是。可以说“之前的方案有些地方需要优化”，但不要说“前任做得不对”。客户问起前任为什么这么做，就回答“我还在了解情况”。
接手FDE项目不是从零开始，是风险识别。第一周的目标不是解决所有问题，而是让客户看到你在做事、你有计划、你靠谱。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
