【高可用架构】项目开发及项目高可用架构的演进探索

“星光不问赶路人,时光不负有心人”
做过一些项目，也带过一些项目，通过摸索，学习，实践，慢慢对一个高可用，稳定的项目架构有了一些初步的了解，将一些做项目方面的心得简单的总结下来，供自己日后查漏补缺，欢迎探讨。

一，项目的来源

总结工作经历中，项目立项的主要几个思路来源如下：

1. 客户诉求

这类来源最直接，由客户主导项目的需求，客户主动提供项目的目标，项目的诉求，项目组根据客户的述求，进行项目需求的整理，项目方案的落地。

2. 行业趋势

通过了解行业最新的趋势，类比行业内的最佳解决方案，向客户提供采用最新最优技术的解决方案，吸引客户的目光，引起客户的兴趣，要量化的体现出新idea能够带来的效益，或者降低的成本。

3. 客户痛点

客户和方案提供方角色不一样，我们多从技术方面去认知，客户会从市场，会从业务方面去认知项目，所以客户会有很多痛点，我们要主动去和客户沟通，了解客户的痛点问题，然后给出落地的方案，尝尝会达到事半功倍的效果。

4. 运营梳理

在系统或平台的运营的过程中，用户，开发，测试，运维，运营等各个角色都会遇到各种无法解决的痛点和问题，或者随着整体的一个大的系统背景的变更，小的系统和平台也需要去适配和变更，这过程也可以攒出项目的落地内容，进行立项。

二，客户的沟通

对于技术人员来说，沟通其实一直是个难题，因为大多数技术人员包括我自己更愿意埋头搞技术，完成一个功能或者修改一个bug带来的快感让我们如痴如醉。但是随着工作经历的增加，我觉得应该埋头干活，抬头思考，开口沟通，动手实践，其中开口沟通一门很重要的技能，能够让我们更加准确的了解客户的真实诉求，找到更好的解决方案。
客户千人千面，不同的客户有不同性格，也有不同的立场，对于不同的客户我们要有不同的沟通着重点。

（图片来自网络，侵删）

客户高级领导：
首先要表明自身和自身团队的技术实例，说明实施这个项目的驱动力，对于长远架构的帮助，列举解决方案和最佳实践，说明自身的优势

客户项目经理：
要进行量化指标，要说明实际的可落地的方案，解决问题的场景，以及对现有流程，现有业务的影响范围，能够带来的收益

客户项目人员：
要说明实际使用的技术，可实施的方案，以及清晰的计划和里程碑

三，项目生命周期管控