相信绝大多数从事IT的朋友们都知道上云已经是整个行业内的大势所趋，激进如互联网企业，保守如传统制造业，乃至于严谨医疗行业也都在准备上云或是已经在上云的路上。
可能有人会觉得，做云架构的话只需要找一些partner让他们搞定不就行了？呵呵，图样图森破。如果一个甲方的IT只能当业务部门和vendor的传话筒，那我个人觉得这个role已经可以考虑直接砍了，还不如直接让业务和vendor接触，不仅能节省人员开支还能减少沟通成本。
在这里我依然想要再强调一下一个甲方IT的重点必定是将技术进行包装裁剪来做到对业务更好的支持，而不是不经过大脑思考的做一个中继直接转发。
那从基础架构的角度来说如何去设计出一个符合业务需求的云服务平台呢?
其实这个Topic是非常庞大的，不管是从IaaS,PaaS,SaaS的角度还是从公有云，私有云，混合云，都是可以扩展出很多的篇幅来讨论。另外做云平台的所需要知识面其实还是相对较多，如果你仍然只停留在网络，虚拟机的层面上来讨论这个问题，那整个输出的架构必定会不够健壮。
接下来我会从整个架构开发方法的迭代来谈一些自己做云架构的经验。在阐述的过程中可能会出现一些不是很恰当的地方，毕竟这些都是个人和理解。说到底其实也只是提供一个思路供大家参考，毕竟每家公司的情况各不相同。
整个Topic我会分为三大块，架构背景，架构定义（过度）以及架构管控。如题目所述，此篇文章的着重点会放在如何在架构开发前期做好一些准备工作，以便开展之后的架构定义。
准备阶段
准备阶段主要关注点是在上云之前的准备工作，并不会产出实际的架构定义，但是这个阶段制定了整个上云的大方向，可以理清思路，少走弯路。
1. 我们为什么要上云？--了解业务驱动和IT战略
在之前的甲方乙方一文中我有提到过一句话就是 No Business No IT，因此归根到底所有的驱动基本上都来自于业务的需求。在这里有一种分析方法俗称大环境分析法，也就是人们常说的PESTEL。
因此我们上云的需求或多或少都来自Political， Economic，Social, technology, environmental以及Legal中的一个或几个。上云的好处我相信网上有大量的信息可以给你想要的答案，随便一搜便是。个人体会是上共有云的费用其实和去数据中心搭建私有云或者虚拟化平台的长期成本不会有太大的差距，无外乎一个是长期的服务费用，另一个是一次性需要投入大量的硬件罢了。更多的好处依然是在云的灵活性，以及底层的托管。其实做Infra的朋友们基本都知道，我们面对的往往更多的是来自Application Team的需求，因为我相信云对大多数业务部门来说可能只是一个很时髦的概念罢了，也不会很关心自己的应用到底是上了云还是落在地上。因此是否上云这件事更多的是由上至下的IT战略推动，或者是基础架构团队自发的技术革新。但归根到底，一个云平台的上线依然是从很多角度直接或者间接的改进了对业务需求的响应。
2.我们准备好上云了么？--了解组织架构并进行成熟度评估
上云其实并不是一件十分容易的事。一般做任何架构之前都要了解到目前的组织是否能够很好的支持到未来的架构模式。对于一个组织来说最重要的其实是PPT(people, process以及Tool）。目前的IT人员是否具有相应的知识储备以及相关技能？目前的团队是否可以在目标的云架构中扛起日后项目和运维的大旗？每个团队的角色和责任又各自是什么？目前的IT相关流程是否适合云平台？目前已有的基础架构在之后的新架构中又是怎样的定位呢？
如果你说我们公司就那么几个人，没有什么特别多的分工，那就当我啥都没说吧。毕竟工欲善其事必先利其器，因此在上云之前不妨先评估一下目标云架构可能需要的一些个人或者团队能力，如果是技术层面可以通过培训或者技术咨询加强对整个云平台的理解和掌握。
3.我们应该怎样上云？--云架构的原则
在做任何架构之前，我们都需要定义架构的原则。架构原则根据不同公司的IT战略会有比较大的区别，但是从云架构来说一般还是比较大同小异，下面可以提供几个作为参考
云资源是自适应并且弹性的
虚拟机是可报废资源
尽可能的自动化
部署上松耦合
关注服务而不是服务器
数据库是一切的基础
尽可能减少单点故障
资源以及费用的最优化
安全至上
以上这些只是一些通用的原则，可以根据具体的业务情况进行修改或者增删，并且也要对每个原则进行细节的描述。在之后的架构设计中如果遇到举棋不定的情况，架构原则将会是你做取舍的最好依据。
4.我们的云上该有些啥？---交付物和框架的裁剪
一般来说在做云架构前我们需从high level 定义到本次架构设计所涉及到的架构层次（应用？中间件？网络？操作系统？数据，等等），由于组织架构的不同，项目范围的不同，所产生的交付物也需要进行裁剪。一般最通用的云架构设计输出可能会包含一系列设计文档涵盖到整个云平台的管理，边界安全，云平台的IaaS和PaaS架构，备份以及灾备，需要集成的第三方组件等等。具体情况具体分析。如果你的架构项目涉及到了应用，数据，业务层，那在此阶段也需要去收集现有相关架构方案信息。
5.我们上云的钱哪里来？---赞助方以及预算评估
给钱的大佬们永远最有话语权，一般发起整个架构开发的往往也同样都是整个架构项目的赞助者，可能是本地IT部门，也有可能是global Team， 也有可能是业务部门，这个取决于各个公司的具体情况。了解项目管理的朋友们都知道一个项目的发起必定需要有赞助者，架构项目也是如此。架构的工作请求也需要从赞助者发起来触发整个开发流程。预算上来说，如果赞助者没有给到固定的预算，在之后的架构初步定义时要做好大致的预算评估。
今天主要先写这点，下一篇依然会是架构背景篇，但是重点将会是架构愿景，可能我会分享一些初步的架构设计思路。如果大家有什么想法也欢迎留言一起讨论。
