背景
公司有个重量级的项目（具体项目就不透露了，后面都用某项目代替吧），一直搞不太好，随着使用的增长，现在各类问题也比较多，特别是一些阻塞类问题，领导有点受不了了，让我们团队出手去搞一下。
原先我们团队已经是出了一个人去支持这个项目，人本身是有能力解决比较多的问题的，但对方也没把人用好，基本上做些边边的工作，也没有太重用这个人，而这个人自己么，也不是很争取，没有摆平这些事，本身这也是个机会，算是没抓住吧！
考虑到在技术管理方面的修行，想着还是记录下，一来帮助自己整理思路，二来记录一下后面也便于回顾，三来，也是最重要的，毕竟要去干涉别人团队的事，要想好自己干涉到什么程度，兼顾好老板的期望，同时也不要让其他团队难看，毕竟人家可能觉得找外援还有点丢份！
一些情况的了解
这个项目因为有人在里面，所以平时周会也会大体了解了一下，对项目中的人和事是有个大概的了解的，因此昨天开会虽没说什么，但基本上当下情况也是有数的，主要的几个点：
1、表面上，现在遇到的问题是系统不稳定，出现阻塞、卡顿，响应时长过长等问题，其根源问题在于两方面，一是技术，团队遇到稍难技术问题，没人hold住，问题原因分析基本靠感觉，没有具体的数据用以佐证，难以从根源上解决问题；二是设计问题，开发各做各的，系统分析师不不清楚业务细节，日常分配完任务就完事，无法在开发开始前进行引导和纠正，没人对不合理的地方说No；
2、迭代发布过程不顺畅，经常有延期，或发布不顺利的情况出现，无法快速迭代，线上问题相对较多，除上述业务设计问题外，还在于过程控制以及部署方式等不到位，过程不够简洁，存在较多可能出问题的环节，属于开发管理上的问题；
3、不论是系统还是人，我都没看明白其职责边界，可能内部确实存在边界不清问题，导致大家在做事的时候无法专注于自己应该专注的部分；
4、整个团队没有一个人清楚当前系统运行状态；
代码方面倒还没有看到，但从原同事的汇报来看，也是存在较多的架构问题的，比如系统划分，分层实现等
解决思路
首先，针对这些问题，已经不是单一性能或功能问题，他是一个系统性的问题，不仅仅包含技术架构，还包括开发管理等方面的问题。若要真正解决，让系统平稳运行，且支持快速迭代，大概的思路应该是这样的：
短期内：
1、解决刺头问题，先让系统在现有架构上能够正常运行，先保证能用，不崩溃；
2、建立简单的日志体系，让整个系统运行处于“可观测”状态，可以掌握系统运行的大体情况；
3、调整和优化开发过程，一是新的功能实现，先保证对，再保证进度，上线就不要出什么问题了；二是优化devops整个过程以及部署方案，使整个代码的变更迭代顺畅起来，做到一周一迭代；
长期： 1、根据当前技术架构的情况，重新设计和规划未来技术架构，包括系统职责定义，系统间关系，外部系统对接，部署优化等，基本解决阻塞、卡顿等问题；
2、旧的业务也能够按更适合团队的技术规范进行调整，解决历史包袱问题；
3、形成完善的日志以及系统监控体系，做到系统运行可控，问题可追踪定位；
4、形成适合团队的一套开发管理方法，使团队能够快速且正确迭代，收敛线上问题到一个合理水平；
基本上经过一段时间的整治，是可以让系统归于平顺的，当然过程中肯定还会遇到各种各样的问题，遇到再解决
想想而已
上述的想法，总得来说，是没有考虑外部因素的，从我们领导的角度来看，是赞同这么做的，但从对方团队甚至对方团队领导的角度，未必就是这么回事。所以应该要做两手准备：
一：如果对方愿意，且较为配合，这种情况也属于比较理想了，那就按上述思路，给他们整治一翻，是可以比较快看到效果的
二：如果对方犹豫不决，或不喜我们做过多的干扰，那就顺着对方意思，协助解决一下当下问题，好了就及时抽身
