https://cloud.tencent.com/developer/article/2303903 运维管理与运维自动化一文中我们从运维工作中提取了运维框架（红色代表缺失），由基础设施层、数据层、应用层、管理层、展示层组成，生成了我们最终的运维体系。
DevOps 是使软件开发和 IT 团队之间的流程自动化的一组实践，以便他们可以更快，更可靠地构建，测试和发布软件。DevOps 的概念建立在建立团队之间协作文化的基础上，这些团队过去一直在相对孤岛中运作。 类似于这种的 DevOps 相关的描述听起来特别抽象，非常学术，非常教科书，让人感觉无法落地，不知道该如何入手。很多团队在了解 DevOps，实践 DevOps 的时候不能很好的多维度看待 DevOps，实践的过程也很痛苦，不知道这种新型的理念如何实际提升自己团队的战斗力。
我一直把运维团队的定位是在技术服务团队，个人也要朝着技术服务的方向去发展。单纯的服务定位对整个团队的发展不是非常有利，会逐渐沦为救火队员和保姆的角色，有点高级人员干着低级的活的感觉。
企业数字化转型，科技先行。国际知名咨询机构如麦肯锡、埃森哲、IDC、IBM等，都在解读数字化定义时提及智能化运营。但要实现智能化，我们还有很长的路要走。
各行各业数字化转型进步飞速的时代，由于企业所处行业和主营业务的不同，运维团队也呈现出不同的划分形式，但随着转型的进程推进，基本上都趋近统一，大同小异。目前互联网行业比较常见的运维部门架构一般包含应用运维、系统运维、网络运维、数据库运维、安全（比较特殊，一般独立小组/部门，或者有一个高级别的领导小组）等部门组成。
随着IT技术的发展，运维需求越来越多样，运维系统的架构也越来越复杂，各公司分别独立建设运维系统的技术和成本要求越来越高，因此越来越多的大型集团企业开始转变思路，考虑建设集团统一的一体化运维系统。
本文作者 Tyler Treat 是一名软件工程师，他认为运维的未来从很多方面来说都跟质量保证（QA）的未来走向相似。未来，运维要使开发者能够通过工具、自动化和流程实现自助服务。传统的运维（ Ops）没有消失，只是在重组。
很好的一本书，读完大受启发。没有讲具体的技术，就像武功秘籍，提升的是认识和见识。1-4章讲运维的基础，5-7章讲效率和稳定性方面的实践，8-9章讲云计算方面的思考和实践，10章讲个人成长与趋势热点分析。最后拓展讲了一下个人成长和趋势热点的关系。
数字化时代，应用成为企业开展各项业务的落脚点。随着业务的快速发展，应用的功能迭代变得越来越频繁、业务系统变得越来越复杂、对IT资源的需求也变得越来越弹性。如何合理高效分配利用底层IT资源、管理上层应用、平衡二者关系，成为企业当下数字化建设中的重要关注点。
如今，随着云计算产业的日益成熟， AIOps、DevOps理念的盛行，大量运维工作通过自动化运维和智能化运维实现，传统运维的生存空间愈发狭窄。
运维是事件驱动，还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障，而自驱动让运维不止于建设。持续性的运维建设就需要一套自动化的运维体系，那么我们应该从何入手？
“ DevOps 是使软件开发和 IT 团队之间的流程自动化的一组实践，以便他们可以更快，更可靠地构建，测试和发布软件。DevOps 的概念建立在建立团队之间协作文化的基础上，这些团队过去一直在相对孤岛中运作。”
基于IT、动环、智能物联网、工业物联网的一体化运维监控需求，不断涌现。这与近两年技术和产品的升级换代，以及越来越多的智能终端在极短的窗口期进入各行业有很大关系。运维平台需要满足新增需求并服务于各种应用场景，一个无可回避的问题已经浮上水面：
因为工作行业的原因，会有很多的同行或朋友找我推荐一些有运维经验的人，或者直接希望要运维专家。
今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的，但也是最容易被忽视的一个环节。
进入2018年以来，IT运维领域最热门的话题可能就是运维自动化，并且这种热门的趋势按照目前的发展态势，应该会继续扩展到2019年、2020年……
抽象的 DevOps “ DevOps 是使软件开发和 IT 团队之间的流程自动化的一组实践，以便他们可以更快，更可靠地构建，测试和发布软件。DevOps 的概念建立在建立团队之间协作文化的基础上，这些团队过去一直在相对孤岛中运作。” 类似于这种的 DevOps 相关的描述听起来特别抽象，非常学术，非常教科书，让人感觉无法落地，不知道该如何入手。很多团队在了解 DevOps，实践 DevOps 的时候不能很好的多维度看待 DevOps，实践的过程也很痛苦，不知道这种新型的理念如何实际提升自己团队的战斗力。
一、为什么要做基线配置管理 一个组织在不同的时期部署了不同的业务系统，承载业务系统的是不同的操作系统和支持系统。业务系统在运行期间，基本上很少做操作系统的升级或变更。再就是由于不同供应商的支持原因，导致现存的操作系统和应用版本跨度很广，安全人员或运维人员资源不够的情况下很难支持做基线配置工作。 对组织的运维和安全人员来说，如果运行的业务系统一直不出事，是想不到要做基线配置、升级补丁、修复漏洞这些事情的，考虑做基线管理，通常来自于3个原因： 合规性性要求，上级安全检查； 遇到安全事件，根源落在安全配置或加固
配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
前言
AI技术及超级计算机在医疗领域的应用，在武汉新型冠状病毒基因测试系列和药品筛查方面，发挥了非常重要的作用。作为这些前沿技术和设备的支撑中心，数据中心基础设施的安全、有序、可控的运维和管理工作至关重要。
早在2011年的时候，收到一个任务，就是自研一套运维管理平台，当时基于硬件（CPU、内存、硬盘、网络）的开源运维平台业已成熟，但为什么要自研呢？
认真评估你的软件的交付机制以及运维团队左移和右移的程度是你选择采用何种 DevOps 分合策略，以及 DevOps 实践是否成功的关键因素。
【名词解释】 腾讯数据中心经理：负责腾讯IDC整体运营管理和属地化管理工作，下文简称“数经”。 腾讯IDC运维工程师：负责腾讯IDC日常IT运维（服务器、网络）、IT资产管理或者IDC基础设施运维，主要分为服务器运维工程师、网络运维工程师、资产管理员、IDC基础设施运维工程师。下文简称“运维工程师”。 【前言】 2015年06月05日，首届腾讯IDC运维工程师培训与认证在深圳总部腾讯大厦圆满落幕，首批参训学员共计20人，其中18位学员通过了“腾讯IDC运维工程师（初级）”认证。此次活动获得了IDC平台部领导
在过去5年，嘉为蓝鲸研发运维运营一体化方案已经在近300家企业中落地。企业类型涵盖了传统的制造、能源，也有互联网性质的互联网金融、游戏。那么，CMDB作为研运一体化方案中非常重要和基础的一环，它的设计理念应该是怎样的？
今晚听了赵成老师关于运维职业发现的分享，对运维最直观的感受是“不要在运维的角度看运维”。
互联网运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够7×24小时为用户提供高质量的服务。 运维人员对公司互联网业务所依赖的基础设施、基础服务、线上业务进行稳定性加强，进行日常巡检发现服务可能存在的隐患，对整体架构进行优化以屏蔽常见的运行故障，多数据中接入提高业务的容灾能力，通过监控、日志分析等技术手段，及时发现和响应服务故障，减少服务中断的时间，使公司的互联网业务符合预期的可用性要求，持续稳定地为用户提供务。 在安全方面，运维人员需要关注业务运行所涉及的各个层面，确保用
你也许可以听听腾讯蓝鲸对于两个问题的解答，或许能够帮你和你的团队拨云见日、一扫愁云，看清未来的方向和出路。
Mikey金字塔是由美国数字服务公司的Mikey Dickerson设计的。层次结构是为了说明，当尝试提高系统可靠性时需要按部就班，在到达更高级别之前满足每个低别级的要求。
联网运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够 7×24 小时为用户提供高质量的服务。
2016/2017年：刚开始做监控的时候，研究了几乎市面上所有监控产品，和相关的技术文章、视频。这个时候，主要是接触了大数据相关的技术，包括：Kafka、Spark、HiTSDB、ELK等。
需要思考这个问题的原因，是因为AIOps不是到了某一个点就突然质变的，而是在持续演进过程中实现的。随着算法的日益成熟，整个运维体系也在改进的过程中逐渐完善，AIOps的道路才会慢慢清晰。因此，在达到目标之前，我们需要仔细规划怎么做才能更快实现AIOps。
最近在做一些运维架构转型的工作，某些思想其实是借鉴了SRE的理念，就和DevOps一样，SRE已经不是一个新鲜的词汇了，尤其是在互联网的行业，无论从组织架构，还是工作属性，都是将SRE，融入其中，成为了软件生命周期中重要的一环。
互联网运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够 7×24 小时为用户提供高质量的服务。
在了解两者的区别前，我们得先明确对二者的定义，总的来说运维工作的目的都是为了保障企业业务连续性，核心在于提供高效、高质量、安全的IT运维服务。
随着企业信息化的不断发展，运维人员需要面对越来越复杂的业务和越来越多样化的用户需求，不断扩展的应用需要越来越合理的模式来保障运维服务能灵活便捷、安全稳定地持续。
上一篇《腾讯蓝鲸是怎样在腾讯诞生的？》一文中，我们谈到了腾讯蓝鲸的转型背景和设计思路。其实在腾讯游戏的内部，有多个应用运维中心，十几个应用运维组，他们各自支持着不同的业务，各自处于不同的发展阶段和能力水平。
随着信息技术的快速发展，IT基础设施运维岗位在企业中扮演着越来越重要的角色。IT基础设施运维是指对IT基础设施进行监控、日常维护和维修保障的过程。这包括网络系统、主机系统、存储/备份系统、终端系统、安全系统、机房动力及环境等基础设施的运维。
作者 | Scott Carey 编译 | 核子可乐 褚杏娟 “谁构建、谁运行”的口号让开发者们倍感压力，但另一方面，运维团队的日子也不好过。那么，这场席卷全球的开发与运维融合浪潮会不会黯然退场？ 根据外媒记者 Scott Carey 的观察，众多开发者纷纷表示“苦 DevOps 久矣”。我们将 Carey 记录的文章在不改变愿意的基础上进行了编译，以飨读者。本文谨代表作者个人观点，不代表 InfoQ 立场。面对争议问题，希望大家理智讨论。 “在大多数情况下，开发人员并不想处理运维问题。”亚马逊
由于数据价值逐渐被重视，相关技术产业逐渐成熟。加上疫情的出现大部分企业开展数字化业务，中国的企业服务市场再一次掀起热浪。
我们的运维工作基本都分布在以上4个层次，因此如何高效、高质量的交付就成为了我们主要面对的问题。
目前，我国IT服务发展已经进入到相对稳定的增长阶段，有着极为可观的市场前景。据相关数据统计，2017年中国IT服务市场规模为6077.7亿元，同比增长16.2%，预计未来四年将保持13.8%年复合增长率，到2021年整体市场规模将突破万亿大关。
一个互联网产品的生成一般经历的过程是：产品经理、需求分析、研发部门开发、测试部门测试、运维部门部署发布以及长期的运行维护。
不久前，在由ACOUG与云和恩墨主办的2018数据技术嘉年华的金融科技实战分论坛上，甜橙金融分享了其云化变革的成功经验。
在之前的文章中，谈到过“运维的本质——可视化”，在可视化的篇幅中，着重介绍自动化的可视化和数据的可视化；在后续的篇章中又介绍了“互联网运维的价值体系”，里面分解了几个维度：质量、成本、效率、安全等。以上都是为了清楚地梳理运维的内容边界，基于这个边界，我们再考虑如何进行平台支撑。可以说前两篇文章都是为今天这篇文章作为铺垫，用理念先行，然后再考虑平台落地，最后再细化其中每个内容。我更习惯用如下的方式来整体表达运维的工作方法和思路：
在很早以前，记得给YY的产品经理讲什么是运维，当时给运维提炼出一个成熟度模型，囿于当时的认识，用技术模型来做了总结，简单总结如下：
作者 | 李大元（Kusion 项目负责人） 后云原生时代 距离 Kubernetes 第一个 commit 已经过去八年多了，以其为代表的云原生技术早已不再是什么新技术，而是现代化应用的“标配”。现代化应用依赖的基础服务远不止 Kubernetes 一种，稍微复杂点的应用往往会同时使用到 Kubernetes 生态云原生技术、IaaS 云服务、企业内部自建系统等各种异构基础设施，可能还会有多云、混合云的部署需求，我们已经进入到了 ”后云原生时代”，只针对 Kubernetes 的运维工具早已不能满足
写在前面
平台工程这个概念越来越火爆，Gartner 的预测，到 2026 年，80% 的软件工程组织将拥有平台工程团队，来提供内部服务、组件和应用程序交付工具，作为可重复使用的资源。
讲师 | 谭用 编辑 | 黄晓轩 讲师简介 谭用 腾讯TEG研发管理部技术运营负责人 负责腾讯企业级研发管理平台建设与技术运营相关工作；十年运维领域工作经验； DevOps Master；近期专注于容
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
