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

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

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

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

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

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

二、因为运维痛并重要！

痛一方面是指运维人员的痛：白天里的工作压力，还有摸黑儿升级系统、半夜被警告突袭的困扰。 另一个方面这痛也是公司的痛：技术上故障问题显而易见，而经济上的损失也不可忽视。国际数据公司（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 运维垂直号，在移动端领取运维优质文章补给。