|
|
又到岁末，就这样默默地在运维行业里已有十年余。总是想找个机会总过去展望未来，并给刚上路或是在路上的运维朋友交流一些观点。虽然现在比前几年轻松，但是惰性也随之有增，所以从未实际提笔。但是因为脑子里一直记着这事儿，所以其实一直在脑子中整理文字和框架，结合工作实际，很多观点也经受了验证，并非侃侃而谈。终于因为圣诞假期开始，趁着回国途中有集中的时间写出来，其实也是为了在万米高空消磨消磨时间。
笔者目前在北美某著名游戏公司从事运维工作，十年间发表过不少文章，著有《Linux系统命令及Shell脚本实践指南》一书。早期是以谈论具体运维实践为主的技术分享，中期主要是一些技术专题，中后期以运维观点、技术趋势为主要谈点，非常清楚的记得5年前发表的文章引起了很多读者的共鸣，但是今天自己在看这篇文章，已经稍显单薄——同时感叹一下岁月如梭，转眼间又一个5年已经过去。我想随着我个人生活、工作重心的转移，我可能不会经常发表文章，所以我也希望把握这次难得发文的机会，力图尽量言简意赅、观点鲜明，绝不浪费有可能读到这篇文章读者的时间。
不得不说这十年，运维行业最大的变化，就是云计算的不断实践和落地，所以无论如何这是十年运维以及未来的主要话题。2006年，也我刚入运维行业的时候，当时运维应该处于近代运维的初期时代，很多现代运维概念还很模糊，但是缺乏技术落地，尚在探索求知的状态。2008年左右云计算开始铺天盖地的提出，却不可能朝夕之间革命性的替换旧有运维体制，造成了当时概念先行的局面，云字也被各种商业生搬硬套的借用，实际上也造成了云概念的错误化传播，而且在运维从业人员当中也鲜有人能真的理解云的概念——很多人可能直到今天还认为云只是“虚拟化”而已。实际上，08年我在上海一家号称全中国第一家云计算公司就职，但是就其工作经历给我的云的概念也是非常含糊甚至有方向性的误导，“业内”人员尚且如此，又何况云外的运维人员呢。09年进入阿里云，让我有了接近学习云的机会，但是正如我说的 ，云的概念即便是在09年，国内从业人员对其有较为深入理解的人并不多，而且因为其底层的发生缓慢，所以就阿里云的从业经历来说，个人太多关注底层的实现，所以虽然理解上有些进步但是实质上并没有突破性理解。但是随后有两年在国家电网从事云计算项目的调研过程中，虽然是离开了云计算一线，但就因为有机会从用户需求的视角来审视云计算，反而能得到清晰的理解。
那么云到底是什么？我相信读者一定听过不少解释。简单来说，云是一种“服务交付”，对用户来说核心在于“服务化”，客户的需求“按需化”、“标准化”，并且实现需求“代码化”，用户对资源管理“接口化”，客户的一切都要回归到以业务为核心的价值上来。还是很抽象，我使用一个例子来说明。假设我是一个红酒批发商，我的需求是借助互联网，售卖红酒。请暂时忘记所有你脑子里的所有对云的想象和理解，剖析我的实际需求：我要“售卖红酒”。但是因为互联网可以让更多人能从网上下单扩大销售渠道，所以我才会“借助互联网”。别嫌我啰嗦，请再次考虑我的“需求”：卖酒！而不是我为了用互联网而花钱玩互联网。好了，一旦要选择使用互联网，我势必要找人帮我写一个web站点或是手机app的代码，并把它部署到互联网上去——而部署到互联网的过程无可避免的要用到机房，实际操作起来，按照老运维的思路无非要购买服务器何必要的网络设备，然后申请机房托管、建设、测试、上线、持续运维。但是这一切在传统运维来说挺麻烦，一套弄好应该按照月计算。但是不能因为走得太久了，而忘记了为何出发，忘记初衷只是为了“卖酒”，其他的一切都是手段而已。而云的服务就在于相同的这一切可以在几分钟内发生——但是这一切都不是魔术，而是实实在在的“服务”，是大量平台代码的实现。随着云计算本身技术的深入，现在几乎所有的可以标注化的组件都成为了服务，目前全球亚马逊的服务列表，已经足以让你除了你自己的应用需要开发之外不需要自行维护任何服务了。请记住：一切的技术手段，只是为了达成最初的目的而已，所以你要学会从老板的视角来考虑问题，成本永远是商业中的核心问题，技术很必要却不重要——我知道这句话很容易展开争论，技术人员天然的认为“技术为王”的天真观点，其实只是一厢情愿而已：要知道所有商业的成功都是基于商业模式的成功，而并非技术的成功，就比如说国内的淘宝成功的替换了易贝，并不是因为淘宝的技术更牛逼。这里不展开，觉得说的不对的去看马云的视频。
那么云技术为什么要花这么长时间来发生？云的概念在确定提出来的时候，确切的说应该是一个“蓝图”，而云慢慢替换旧时代需要在方向正确的基础上埋头实践。这就和十年来国内的高铁建设一样，如果说高铁线路的铺通是整个计划的基础支持，那么云计算也一样无法在短时间内发生，但是它的替换趋势虽是缓慢发生却又是不可逆转的。所以如果你是运维新人，请坚信我的观点，借助云计算的敏捷运维是未来10年内必然的方向，而如果你是个老运维人但是不幸还在坚持传统观点，我建议是时间刷新观点的时候了——实际上，运维在经历了早期比较杂论后（或是混乱的阶段），运维自动化概念的提出在很大程度上的实践并不是利用云，而是在维持当前架构的基础上更多的引入高可用、服务自动发现、故障自动修复、工具化部署来串联，甚至不少公司会根据实际情况自主开发这些系统。但是所有这些系统，如果你真实的学习并了解了云的核心概念，你会发现这些都是云的初始化思维，而引入云将天然的解决传统架构的这些问题——这里我无法给你解释，就像有时候你无法给别人描述别人没有见多的东西一样。实际上在我们公司内部之前也有这样的系统，集结了公司里最好的程序员团队——刚开发出来的两年内在公司里好评如潮，而我却一直对这个方向抱有警惕之心，并在我能触及到的范围内表达我的顾虑——如果这不幸是公司高层的认知将会非常遗憾。但是随着公司云化方向的不断深入，该项目已经在一年前全面停止开发并在未来2到3年内全面停止使用，而这个团队的成员也如同英雄谢幕般各自离去。
有个冰冷的现实：云的缓慢推进一直有很大的阻力来自于运维从业人员本身，因为对其不了解和片面的认知。拒绝云计算的一些典型的错误论点有：
1.云计算不适合我们的应用。这个观点曾经在我们团队内多次讨论，这个理由也最被坚持。我目前从事游戏行业，刚进入游戏行业的第一年每每提出利用云的快捷便利便会有人提出这个观点——实际上两年后，受益于公司高层全面的云化决定，目前中国游戏除了生产环境之外其他所有环境都已经迁移到云中，而北美游戏服务也将会在一两年内全面云化，所有“不适合”的观点不攻自破。云中的一切不是资源就是容器（不是容器技术，就是字面容器的意思）——所以“不适合”的说法，没有实际的立足点。更多的只是旧有思想的坚持，说到底还是对“新”事物的不理解、不学习。这里新字我打了引号，其实云早已成熟落地，很快都要变成夕阳产业了。
2.安全性顾虑。安全相是对而言的，传统架构也有安全漏洞，从安全性上很难说谁更好更坏。另外，安全是个动态的拉锯过程：今天的固若金汤明天就可能因为某个漏洞有被打成筛子的风险，安全从来就是一场攻守战，道高一尺魔高一丈，只要不是完全隔离，哪有完全安全的系统。
3.性能顾虑。云从来不强调性能，但是却具有更大性能扩展可能，对于性能的比较要建立在同等投入的基础上——从老板的角度去考虑问题，从技术的角度去解决问题。同样是拿出一千块，在云里已经大有所为，但在传统运维几乎中几乎还什么都做不了；丢进去同样的成本，云计算只能能吐出更多的性能。
既然说未来的运维基于云，那么未来运维的趋势是什么呢？我认为以下几点将是具体表现形式：代码化、简单化、接口化、专业化、持续集成化，我一一做些解释。
代码化：不仅仅是简化了过程，还简化了重建、复制和迁移，不但有助于一般故障恢复，也是未来的新型“灾备”形式。但我这里要指明“简单化”其实对运维人员提出了更多的要求，所有的需求找出它的流程并标准化整个流程，把流程代码化，能封装的过程尽量封装，一个按钮能包含的必要的自动化过程越多越好，并不断的优化出错（exception）处理。
运维简单化：“简单的东西不一定好，好的东西一定简单”——我们向来善于把简单的东西复杂化，而复杂事情简单化不仅需要智慧，有时候还需要你对未来趋势的把控，所以其实是对运维人员提出了更高的要求，能有效提升自己、优化系统的一个方法是经常反问自己，当前是否依然复杂？是否还能继续简化？能否尽量将必要的操作步骤降到最少？当前的系统是否对使用人员有太多提前需要学习和知道的要求？我的系统里面是否能做到零Trick？越来越多的Trick只会把团队拉入低效的深渊，消磨团队的意志并降低团队效率。
运维专业化：为什么这么说，难道现在的运维人员都不“专业”么？不是，有“专”的运维，比如说DBA就是大运维里面独立出去的“专门从事DBA行业”的人员，其他很多运维人员都是专业的从事不专业的工作，哪里有火去哪里，不管懂不懂都得上，看似运维应该“什么都懂”，但是什么都懂的真实含义是什么都不精，这种模式非常低效而且给从业人员带来很大的工作压力，不利于运维人员的成长，从粗放到细化的分工会持续，“专业”就是有所为、有所不为。
运维接口化：核心是“服务”的概念。现在的运维团队之间很多的交流还发生在口头上的沟通，有问题办公室里（或是群里）喊一声，而未来这样的现状必定会一接口化为实现：定义各个服务之间的调用，以此实现服务之间的解耦，现在很多应用的运行依赖于很多周边服务，而应用在出错的时候，需要排查整个工作流，或者是在茫茫日志中寻找错误，然后猜测出错组件。而接口化的运维将完全简化这个过程。运维接口化是也运维专业化的具体实践方式之一，而正因为这样，运维已经从十年前的简单粗暴、对人员技术要求不高转化成对从业人员提出越来越高的要求，这也是当前老运维人必须接受的变化。
持续集成化：这是未来敏捷开发、高效迭代的必要支撑，运维要能做到对应用的迅速部署和测试，提高项目迭代的效率。当从基础交付到存储、数据库、部署都已经成为标准服务接口之后，未来越来越多的互联网公司都将只需要维护虚拟机房（基础架构代码化）和应用的快速迭代部署（持续集成化），所以如何持续推动简单化维护是未来运维的必然趋势。
总结一下个人觉得运维从业者应该抱有的态度：
1.不断的学习，特别是对新生的技术要抱着包容的态度去学习：没有完美的技术，只有完美的借鉴。
2.谦虚谨慎，对不了解的技术保持敬畏并慎重发表评论，一定会有行家，夸夸其谈无非贻笑大方。
3.在学习和了解的基础上形成你自己的技术观点，有理有据的表达观点，对技术片面的批判如果缺乏坚实论据的支撑，除了会成功的慢慢欺骗到自己之外没有任何好处。
4.必要时要脱离技术本身，学会从老板和客户的观点去考虑问题。
5.方法论是能够更快学习的催化剂，能宏观的看技术更有乐趣。
6.如果你能做到以上几点，那么有论据的坚持你的观点，不要害怕你是少数派，牛羊成群，狮虎独行。
不知不觉，啰啰嗦嗦，看似不多的文字写了四五个小时，行程过半。希望如果有一天当你看到了能给你一些帮助或是灵感，如有好的想法或是交流可以给我留言或是QQ110766894交流，请注明“技术沟通”否则不予通过。文末友情提醒一下大家：国内很多云计算可能对市场有一些妥协所以方向上稍显偏颇，所以真的想更深入的了解云计算，多看看国外某云相关的书比较靠谱。
最后祝大家新的一年里继续成长！
----------------------------
原文链接:https://blog.51cto.com/johnwang/1883857
原作者:王军
程序猿的技术大观园：www.javathinker.net
[这个贴子最后由 flybird 在 2020-01-28 17:28:59 重新编辑]
|
网站系统异常
| 系统异常信息 |
Request URL:
http://www.javathinker.net/WEB-INF/lybbs/jsp/topic.jsp?postID=1638&replyID=0&skin=1&saveSkin=true&pages=1&replyNum=
java.lang.NullPointerException
如果你不知道错误发生的原因，请把上面完整的信息提交给本站管理人员。
|
|
Java技术网站 → 『 Java开发技术 』 → 『 操作系统、网络架构和数据库专题 』 → 从十年运维看“云”维趋势
消息
查看
搜索
好友
邮件
复制
引用