还曾记得上一次写博客已经是八九年前，那时候凭借着自己刚合格的高中语文水平以及一股满腔的热血写了好多不着边的东西。那为何现在又要重新拾起笔头呢？
作为一个从业IT将近十年，算是有一定经验的行业人员。回首往事，自己的成长之路居然没有留下那么一丁点的笔墨。如果哪天记忆力衰退，估计那些脚印也就一并随风而去了……
作为一个甲乙方都瞎混过的IT工程师，我有过许许多多不同的体会。因此与其他的IT博客不同的是，我更会着重于从甲方的角度去看待现有行业内的一些技术，方案，架构以及流程。由于个人的技术背景更偏重于基础架构以及云服务，因此应用层的以及数据层的技术不会有过多深入的分享。如果有遇到哪些比较有意思的Topic也会发表一些愚见和分析。但更多的能看到的是我在日常工作中在云上的一些案例以及最佳实践，以及一个甲方IT在面对众多选择时可能会涉及的一些考量。
在更深一步探讨之前，我还是要在这里简单介绍一下自己。本人目前在某个体外诊断行业龙头企业内担任资深基础架构顾问，主攻云服务方向。也许你会问，为啥你不是云架构师呢？因为公司没这个role……有点偏题了……之前有在某国际涂料巨头也担任过四年基础架构专家主攻数据中心和虚拟化，这就是我目前仅有的甲方IT经验。再往前就是在微软待过两年，主要support过O365以及windows相关产品。最后也顺便提一下，我毕业第一年的时候其实是一名网络工程师，主要负责城域网交换机的产品支持以及项目上线。在认证方面，除了技术层面的思科CCNP(不好意思不是IE)，微软MCSE, Azure Architecting之外还有一些例如ITIL Foundation, PMP以及TOGAF的证书。
在技术层我更是偏微软系的，然而事实证明微软在近几年来的确比较给力，我个人也比较看好。同时你们也会发现我也有一些非技术层面的认证，这也是甲方和乙方比较重要的区别之一。
接下来的篇幅我会分享一些我在甲方IT部门的一些体会，可能对一些乙方的朋友们也会有一些帮助，但由于我目前只在外资企业工作过，因此这些经验可能不适用于国内私企和国企。
一，重业务多于技术
在绝大多数企业这个理念是毋庸置疑的。尤其是在业务高速发展时期，为了业务的及时上线，应用底层做的跟屎一样漏洞百出也是常有的事。此外很少有甲方公司会自己养一堆技术性人才来开发维护自己的系统。更多的是将技术层面外包给专业的IT咨询公司，体量比较大的可能自己的IT部门单独拉出去成立一家实体子公司，为母公司服务，也有把IT层直接全扔给global team来管理。
因此想要纯靠技术在一家甲方公司呼风唤雨这可以说是痴人说梦。一个有价值的甲方技术IT更多的着重点必定是在将技术进行包装裁剪，将通用的解决方案改进为组织特定方案来满足业务的需求。这也是为什么在绝大多数情况下，业务架构是优先于应用，数据和技术架构的原因。毕竟一句名言说的好：No business No IT.
二，重管理多于技术
虽然说IT的本质是技术，但是作为一个甲方IT，纯技术的东西就像是未加工的食材，我们的业务是难以直接将其下咽。而服务和管理则是对技术本身的再加工，可以提供出让客户满意的IT服务并为业务保驾护航。这里会有许许多多重要的角色, 比如服务交付经理，产品经理，项目经理等，都是从各个不同的维度满足业务的需求。
三，管理or业务？
这个并没有绝对的谁对谁错，一般来说业务发展期重业务，稳定期重管理。当然，稳定期一般也是砍预算和砍人的最佳时机，你懂的。
四，重架构多于方案
架构是比较high level的一个顶层设计，可以理解为政治上的正确。这里另外一句名言也就来了：No Arch No solution。没有规矩不成方圆，任何不在Architecture Landscape内的building blocks 一般都不会被随意采纳，即便某些乙方的产品的确挺不错。因为复用现有的solution building blocks一般都是最优先高效的。当然除非在做差距分析时有发现有缺失，企业才会考虑再开发或者采购新的方案。
五，Global IT Policy永远是对的
Global IT Policy可以理解为一个国家的宪法政策，即便你觉得有无法理解的地方，但是你必须执行。在选厂家的时候尤其明显，比如网络设备外企都是思科为主。云服务一般都是微软亚马逊，比较少会选用阿里腾讯，因为Global IT policy不允许，当然上有政策下对策，其实也有打擦边球办法，具体我就不描述了怕说多了被查水表。有的时候你也不得不说一家外企的某些产品选型其实很大程度上取决于CIO的喜好，就是会有公司在中国业务占比比较大的情况下依然坚持使用404服务来取代微软的产品，这个不好多说，因为这就是政治正确，你懂的。另外一般外企对compliance尤其重视，重视到可能因为一些看似不重要的事情让你一年的工作评分毁于一旦。所以上厕所时一定要记得锁屏。
六，永远存在的GAP
这里的Gap并不一定是指技术层面，更多的是role and responsibility的不明确，导致了某些事情不断扯皮难以推进。这个或多或少在任何一个甲方公司都是无法逃避的存在，但是个人体会是一个善断的IT head一般可以比较好的缓解这方面的问题。因为很多事情either way都是可以work的，说到底都不过是利益的牵扯罢了。
以上这些有些可能在日后某些分享中举例说明，也有些可能就不再提了。另外最近我完成了现公司在微软云上所有的架构设计并全部文档化，由于保密协议我不可能将文档内容在博客内分享。但在之后的文章里我会分享一些在云上的最佳实践以及遇到的一些坑。
其实很多事情并没有绝对的对与错，如何做出最适合自己的选择往往才是难点所在。做方案和架构也依然如此。希望有朋友能在看过这些带有我个人主观色彩的的文章后获得一些启发，并且能够指出我的不足和问题，互相学习互相进步。
