因为那里有光——高效开发运维微信号开篇记

  • 木环

2016 年 9 月 1 日

话题:语言 & 开发架构其他运维

为什么要做运维的微信号?

一、因为运维工作要求太多!

运维内容太庞杂,坑多水深。运维工作者们胸中首先装得下夯实的基础知识:上知网络技术,下晓硬件知识,融会贯通各类基础服务;玩得转得操作系统,搞得懂虚拟化,整得了数据库,照顾得过来安全。其次,肚子里藏得下实践经验:选用运维平台及工具,配置和部署软硬件,管理资源和对应权限,监控分析及时报警。最重要的是故障发生后第一时间即可被解决,要是能性能调优、优化和开发系统当然最好啦。哦对,还有...... 等等,你确定指的仅仅对运维这一个工作岗位的?同时,按公司的运维成熟度运维系统可以划分为四个阶段:人工化、规范化、自动化和智能化;相应地,运维工作的内容和目标则又会千差万别。

真正把一个系统给运维好是需要很深厚的功力,开发运维那些周边工具所花的时间精力,很可能比研发中间件核心花的时间还要多很多。

——阿里云中间件专家 赵林

二、因为运维痛并重要!

痛一方面是指运维人员的痛:白天里的工作压力,还有摸黑儿升级系统、半夜被警告突袭的困扰。 另一个方面这痛也是公司的痛:技术上故障问题显而易见,而经济上的损失也不可忽视。国际数据公司(IDC)VP Steven Elliot 先生在指出,对于世界 1000 强公司,一个应用致命错误修复成本为每小时 50 万到 100 万美元,系统宕机一小时将会造成 12.5 到 25 亿美元的损失。并且建议每个公司都根据自身的商业模型,对运维成本使用算式进行计算:

停机费用成本 = 部署频率 * 版本迭代失败概率 * 平均修复时间 * 断电的金钱损失

传统观点中,运维并不直接带来利润;但是在当今对 IT 高度依赖的时代,运维已经成为了公司利润的重要保障。

IT 已经从服务支持中心开始转变成利润驱动中心。20 年前,如果中国互联网中断一个小时,不会引起轩然大波;但是,如果现在互联网整体宕机一个小时,这不只是技术问题,更将是国民经济的损失。

——青云 CEO 黄允松

在这个新时代,如果还想单纯依靠人力,而不是从技术、组织、思想层面去改变和提升,怕是会一步慢步步慢,乃至再无追赶弥补之机会。这也是为什么,运维开始受到业内越来越多的重视。

运维是 IT 大后方的强有力支撑,小编真心认为运维人员是拯救 IT 界的英雄呀!

三、因为为技术人员服务是使命呀!

作为技术知识的链接者,InfoQ 十年如一日,汇集优质学习资源呈现给大家。而今,InfoQ 旗下的高效运维开发微信号正式成立,服务于广大运维工作者,献上技术知识的支持。

不愿你独自硬扛着沉甸甸责任,而没有技术上的支援和精神上的鼓励。

不愿你困在某个技术点,遍询四处却不得既中肯又实用的建议。

不愿你日夜为工作奔波,早已无暇享受哪怕片刻的轻松生活时光。

愿在你的后方提供运维的补给;

愿看着你在工作中屡立战功;

愿遥祝你成为公司的中流砥柱。

为什么要强调“开发运维”?

高效开发运维这个名字的灵感主要来源在 DevOps 一词,DevOps 突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。 DevOps 概念早先升温于 2009 年的欧洲,是为了解决传统模式的运维之痛。

2009 年,Flicker 宣布每天可以支持 10+ 次的软件迭代部署,至今仍为交口称赞的范例。DevOps 之所以能够有效提高软件迭代,是因为可以形成下面的这个闭环。

目前在国外,互联网巨头如 Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb,传统软件公司如 Adobe、IBM、Microsoft、SAP 等,亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用 DevOps 或提供相关支持产品。我们期望的是推动 DevOps 在国内的发展。

DevOps 给传统运维带来了不少考验,但同时也带来了巨大机会。怎么利用好开源世界,怎么从运维转变为 DevOps,需要很多智慧和努力。在大数据的环境下,DevOps 的挑战将更加艰巨。

——TalkingData 运维总监 潘松柏

此外,从运维人员的个人角度而言,成为一名运维精英,仅仅掌握基础的运维技能是不足够的,必须兼顾提升开发能力。管理大规模集群时,如何做到心中有数、运筹‘维’幄?在运维系统面临重大挑战时,如何能做到一人当关、万夫莫开?

这个微信公众号会提供什么?

首先向运维社区的先行者致敬,运维圈的活跃需要不断有技术专家们的积极分享。高效开发运维将会全心全意地奉献上运维领域的优质内容。

我们的内容将围绕但不仅限于 DevOps 的工作环:

狭义的 DevOps 强调开发运维之间融合,我认为广义 DevOps 需要从应用的全生命周期考虑,实现全生命周期的工具集成和跨团队的线上协作能力。实施 DevOps 需要从组织、技术、流程、文化四个维度着手,最终促进从项目敏捷走向企业敏捷。

——普元软件产品部副总 刘相

我们不会局限在狭义的 DevOps 之上。2004 年,NASA 美国国家航空航天局开始提高研究软件部署频率时,DevOps 这个词还没有被发明出来。近年来,DevOps 的开始被越来越多的企业使用,一是得益于核心技术的整体发展,包括云计算、容器技术等; 二是得益于各类相关工具的成熟,如 CI/CD、自动化测试、资源管理、监控等领域。 口号运动不重要,重要的是怎样能将技术踏踏实实地落地。

所以,与其说我们关注 DevOps,不如说我们更在意的是 DevOps 的初心——怎样在保持稳定的前提下,提高产品迭代;让运维更有效地交付并实现 IT 价值。

高效运维开发会为读者们链接更多的技术专家、分享更多的实践经验,倾尽全力为你们呈现干货内容。随时欢迎大家提供宝贵建议。

PS. 编外语

2013 年的夏天,坐标欧洲一家全球前 50 强的传统行业公司,小编在 IT 架构部做实习生,独自一人搭建 ELK 日志分析平台。当时 ElasticSearch 还刚刚兴起,技术资料并不多,处在抓耳挠腮乃至挠墙的受困状态,搜到了一篇 InfoQ 外文站的相关文章,如获至宝,最终成功搭建单机实验版 ELK,公司之后采用方案整合入内部大数据平台并部署到集团服务器。小编相信自己绝不是唯一一个 InfoQ 受益者。

InfoQ 一直也将继续陪伴技术人,用优质的技术文章作长情的告白。

技术提升世界的活交给你们了,高效开发运维在这里给你们提供后勤补给。

欢迎关注 InfoQ 运维垂直号,在移动端领取运维优质文章补给。

语言 & 开发架构其他运维