近期某项目的问题总结与思考

       最近我们做了一个项目，是教学实验场景。项目内容是为学校建设一个涵盖软硬件完整环境的大数据实验室，包括实验室基础硬件设施和系统软硬件。我是项目技术经理，总体负责软件部分交付，同时作为其中的GoIN分析系统产品负责人负责相关内容交付。在几个月交付过程中，遇到了很多问题。

       项目一开始没有人能明确给出系统会如何使用，我们产品研发团队也几乎没有教学和实验场景的项目实施经验。一开始项目经理、产品经理直接给我们传达需求，就说基于GoIN产品上做几个案例，案例内容让我们自己设计，没有具体要求。这是第一个问题。

       那会儿是6月前，公司还没调整组织架构，我的一个副手一直在跟进这个项目，我自己并没花太多精力在这个项目上。6月公司调整，成立交付中心，我副手调到了交付中心做项目经理负责其他项目，我被确定为这个项目的技术经理负责整体系统交付。现场部署实施很快提上了日程，但在7月底之前一直没有确定部署时间。这是第二个问题。

       项目确定8月下旬部署到现场，项目经理要求我们的系统需要满足合同指标，满足验收条件。直到这个时候，跟用户（也就是学校老师）也没有沟通过，研发团队都是对照合同指标进行交付，需求其实并没有传达到位，也许是项目经理和产品经理觉得很有把握吧。这是第三个问题。

       事实上因为项目实施过程经历了公司变动、人员调整、制度变化，大家都没有调整过来。我作为技术经理，没有充分预估到项目后期、尤其是到现场部署实施、上线运行阶段的出现各种技术问题、需求调整的可能情况，在5-7月的案例开发环节以及对社交媒体分析系统的研发团队疏于管理，导致了整个研发团队在系统部署到现场的时候，研发费用已经用完了。在这种情况下，后续的投入，比如安排研发人员到现场解决问题、协调测试人员到现场测试以及客户现场位置偏远需要打车等，都因为预算问题一度较为尴尬。尽管后来经过多方协商，领导最后拍板由研发中心承担。这是第四个问题。

      项目内容包含服务器采购。为了减少去现场的实施成本，跟项目经理商量先把服务器运到公司进行几个软件系统的部署。一切部署完毕之后，经过研发人员简单自测，就把服务器拉到客户现场。一天，做社交媒体系统案例的同事去现场补充一些案例数据，结束之后没太注意，就让她直接按服务器电源键强制关机，结果出问题了。第二天项目经理去启动服务器，大数据基础平台起不来，导致了社交媒体和GoIN也起不来。远程看了下原因，是因为ElasticSearch、MongoDB等数据库组件所在硬盘丢数据，有的硬盘甚至没法正常挂载，从而业务起不来。一开始想推责给曙光，认为他们服务器质量不行，强制关机怎么连硬盘都挂不上呢，需要给我们提供解决方案！后来曙光派工程师到现场检测，说硬件没问题，也不负责数据恢复。没办法，毕竟是我们自己强制关机导致的，我们只能安排相关同事重新部署。网上查了一些资料，基本都说服务器强制关机经常会导致丢数据。没有足够重视关机，这是第五个问题。

       服务重新恢复后，让大家都记得不要强制关机，而是要通过执行系统关机命令shutdown进行关机。万万没想到的是，实验室因为有其他教室装修，导致突然断电，而这突然断电，又一次导致系统起不来。尽管因为之前的部署中已经写好了一些脚本，数据库组件重新部署后可以快速恢复数据，但毕竟也是个事儿，还不一定会导致其他哪些服务也起不来，因此我们就跟学校协调，看能不能给配置UPS。结果学校老师说，因为之前有机房UPS导致起火，所以学校禁止机房安装UPS。然后跟项目经理商量，让老师每次下课的时候，都把服务器正常关机，下次要上课的时候，提前开机。为此，我设计了在一台服务器上部署一个REST服务，接到请求后逐台服务器通过SSH免密执行关机命令。又在windows教师机上给安装了curl命令，写好请求关机服务的bat脚本和说明文字，这样老师通过执行命令一键关机。这个方式截至目前为止的多次上下课的反复测试，基本没有出现丢数据、组件服务被破坏的问题。以前做的项目，机房基本上从不断电，如果要断电，也会提前通知我们做好备份，然后通过关机命令关机。而这次，实验室的服务器摆在单独的机柜，没有集中的机房、没有接入学校网络、电源不稳定、没有UPS，为了避免不确定的突然断电导致系统崩溃，竟然需要频繁地开关机，而这对于大数据系统的众多服务组件和复杂架构依赖显然是一个很大的挑战。老师到现在还在跟我们说，需要有一个彻底的解决方案。这是第六个问题。

       终于要交付使用了。按照惯例，验收通常比较容易，但是让用户用的满意则比较麻烦。甚至可以说，面向行业的项目要同时满足合同指标与用户实际使用的双重需求。对于这一点，我是有心理准备的，所以在验收会结束后，我就在项目组微信群里说，大家前面的工作很辛苦不容易，但验收只是一个阶段性胜利，系统实际投入使用后还将有不少工作要做。但在后来给老师做系统使用培训时老师提出的很多意见，让我意识到之前还是低估了实际的难度。最大的问题在于，GoIN系统以及社交媒体分析系统都不是面向教学和实验场景设计的。在教学场景中，老师通过演示系统，是为了给学生演示或解释一个问题或一个技术原理，因此系统应该尽可能简洁易用、有示意性（intuitive）；在实验场景中，学生使用实验系统，是为了加深理论理解，掌握相关分析方法，因此也要求系统简洁易用、有示意性，同时还要保证过程清晰完整、分析结果准确可复现。对于这个需求认知的gap，我认为是项目经理和产品经理给我们研发团队挖的最大的坑，因为理应由他们在前期做好针对教学实验场景的应用设计，而不是等项目到了这个阶段，马上就要给老师和学生实际使用了，才真正明白系统将会被如何使用。这是第七个问题。另外，也不得不吐槽，项目前期项目经理和产品经理不知道出于什么目的，反复跟我强调系统不会被真正使用，只要满足合同指标要求就可以，然后我们竟然就相信了他们，没有关注真正的业务需求。

       为了尽量解决系统设计场景的差异，我们按老师要求对系统配套案例进行修改，对案例操作手册进行了调整，学生通过查看手册，更加清楚分析目的和操作过程。另外，为了满足不同班级的上课需求，设计了自动批量创建学生账号的脚本，创建账号的同时把案例相关数据分享给所有学生。GoIN由于本来面向用户的独立分析，因此数据分享都是单独进行的，而现在一个班级都有几十上百的学生，哪怕再简单的步骤，也会让老师感到厌烦。另外老师提出的恢复系统数据、清空学生数据等需求，目前暂未实现，后面还需要投入。

       诚然，面向教学实验场景的系统，老师是主要用户、学生是次要用户，服务好老师是首要的。但是，如果学生使用过程中遇到太多问题，也会影响教学质量，影响老师对系统的评价。学生会如何使用系统？尤其是大数据分析系统，强交互如GoIN？有可能平时不怎么使用，认为不重要的功能，学生反倒感兴趣。另外，老师有可能带着学生一起同步操作，也可能安排一个任务让学生自己去做。因此系统的可用性、稳定性，包括响应时间、并发访问能力，都很重要。其实系统功能不需要多么丰富和复杂，也不需要具备大规模的数据（尽管是大数据分析实验课），但GoIN的设计目标就是要工具丰富，要强交互，要分析大量数据。在情报分析中，用户把系统作为辅助工具，怀着“系统可能产生意想不到的情报”的微弱希望，但不会完全依赖系统。而学生是来学习知识的，知识图谱、自然语言处理、图计算、可视化、关联分析、时空分析、统计分析等等，不管是什么，让学生学到知识最重要。

       对软件系统的质量，有功能性和非功能性的。我们往往太重视功能的丰富，一轮轮迭代增加各种功能，而不够重视非功能性特性，然后就导致一旦投入使用，就出现各种问题，包括BUG、稳定性、性能等。对于GoIN系统我是一直有这方面的隐忧，即便在去年7月以后不再迭代产品，实际上也在持续解决相关问题。对于功能BUG，的确是由于产品测试较为仓促，没有细测就发版，同时也有后来一直在迭代但并没有经过测试导致的不完善。对于系统性能，我查看了GoIN v1.1的需求设计，当时的确提出了对于并发、数据推送、图谱浏览、可视化渲染等方面的性能指标，然而也是因为资源和时间限制，并没有进行严格的性能测试，尤其是对于后台服务、SQLGraph在何种数据规模、何种用户并发规模情况下的内存需求没有仔细评估。基于此，系统实际使用中不管出现什么状况，我理应负主要责任。

      上周五第一次上课，老师在讲解了理论知识后，让学生自己对照案例视频或手册进行系统操作。当时主要出现2个问题，一个是部分案例数据没有分享给学生导致案例无法复现，另一个问题是系统部分操作卡顿甚至浏览器崩溃。这周二第二次上课，老师带着学生一起操作，由于部分案例数据分享给学生后处于未加载状态，学生一起去加载，导致SQLGraph瞬间接到大量图加载的请求，大部分学生无法继续进行操作。后台日志显示，加载过程中SQLGraph找不到部分数据，同时有个别记录显示SQLGraph内存溢出。初步分析是因为内存不足的原因，后来发现系统配置太低，但上课期间没法重启系统。尽管当时向老师做出了解释，下课后老师还是非常生气，把销售、项目经理和我叫过去，表达了极度不满，并声言如果周五课程再出问题，就不给付钱。事后我们赶紧跟公司领导协调资源、讨论解决办法，通过多种优化方式，总算是保证了周五的顺利。

       到现在，尽管已经出现了这么多问题，也对系统做了很多优化，但仍然无法保证能够完全满足后续的实际需求。但是我认为，只有经过了这样实际场景的考验，系统才能更加完善，成为真正有用的产品。

       过程虽然会痛苦，但结果一定会是好的。