- 综合排序
- 最热优先
- 最新优先
- 来自专栏互联网老辛
运维所需技能体系
而运维在这个生命周期中的每个阶段都有可能参与： 设计阶段： 主要针对系统架构设计的合理性进行评估，包括是否存在单点，是否可以容错，是否有强耦合等。 通过运维的基本工作，我们来看看一个运维人员需要掌握的知识体系： 操作系统： Ubuntu,CentOS，Redhat web： nginx,apache ，tomcat 监控： zabbix 在众多的技能体系中，很多人习惯于研究一个又一个关键永远都学不完。其实运维的发展是从最原始的人工阶段慢慢过渡到工具和自动化阶段，最后才是平台化阶段。 很多人提高了智能运维，其实智能运维的应用已经在国内的百度，搜狗，阿里等企业开始尝试和摸索。 目前智能运维主要被用于故障分析，根据故障的现象，快速定位问题。 智能运维还不是小公司的研究范畴，但总有一天会被普及。当然我们也不必因为智能的发展而忧心忡忡，毕竟时间万物的发展，有新的事务出现，必将有新的岗位代替旧的岗位。 我们只要用心去掌握新岗位的技能就行了。
1.2K20发布于 2018-12-06 - 来自专栏PT运维技术
运维体系建设套路
先谈流程体系的建设: 新时代的运维已经不涉及IDC机房，交换机，路由器，服务器硬件，各种中间件和基础组件。 这种现状会让运维会站在从研发到应用交付的层面上看待运维保障工作，因此运维的规划可以集中在研发效能体系建设，监控体系建设，变更体系建设，最后是运营体系建设。 先谈一下基础体系--变更体系，线上的变更：涉及到运维基础层，运维应用层，应用层，业务层， 变更的所属层级越低，影响面和破坏力就越大。 专业技术方面的建设： 发现问题是监控体系干的事情，解决问题是运维事件管理/运维问题管理等偏向技术运营体系干的事情， 两者相互促进。 告警事件产生的问题/或者人为反馈的问题（技术相关的），转交到运维人员手中，运维人员有不同的处理方式来解决。一种是较浅层次就事解决事。
1.8K11编辑于 2022-06-14 - 来自专栏杨建荣的学习笔记
运维开发体系梳理
这是学习笔记的第 1890 篇文章 今天把运维开发的体系做了一层梳理，基本把一个整体的脉络理清楚了，这部分的内容也会不断萃取和整理，希望能够给大家一些参考。 ? 所以把shell也揉入了进来，基本的系统管理和脚本开发是运维开发的基本功。 基于web的运维开发技术，是在基础开发的部分衍生出来的，掌握了基本的Python技术不一定能够完全掌握基于web的开发技术，因为不是完整的一个技术栈，web方向涉及的知识体系相对要大得多，而且会很杂。 架构和设计是运维开发里面的难点部分，其中自动化运维的架构设计部分就好比是画一幅画，如果把轮廓画好了，基本上画的质量和效果是可以预见的。一个松散没有良好架构设计的系统是很脆弱的，也是经不起考验的。 运维管理模块我会主要从基础运维，备份恢复，高可用管理，分布式管理几个部分进行产品设计和集成实现。
1.8K20发布于 2019-03-07 - 来自专栏IT不难技术家园
运维知识体系总结
运维知识体系 基础设施层 公有云，私有云（OpenStack/cloudstack + KVM/XEN，oVirt), 混合云 服务监控 配置管理 硬件选型、配件更换、资产录入、系统安装（Cobbler 开源：LVS（IP负载均衡）+Keepalived、Haproxy 商业：F5、Netscaler 七层负载均衡 反向代理：Haproxy、Nginx、Apache（根据HTTP协议支持的属性进行L7分发 运维管理体系 ITSM ITIL V3 IT Service CMM Six Sigma DevOps Master 项目管理（PMBok） 知识体系 运维方案 容量规划 灾备规划 服务降级 运维协助 性能测试（TCPCopy，日志转换） 单机监控（nmon） 环境规划（开发，测试，预生产，生产） CI（持续集成）自动化部署 Operations as a Service 运维咨询 运维托管 技术培训 应急处理 产品即服务 DevOps专家服务 参考: 运维知识体系
1.2K31编辑于 2023-11-17 - 来自专栏北京马哥教育
浅谈运维工具体系
运维行业正在变革，推荐阅读：30万年薪Linux运维工程师成长魔法 运维流程管理工具 发布变更流程管理工具：做为系统接口与其他角色的工作衔接。并提供审批环节控制发布变更的风险。 运维发布变更工具 版本管理工具（数据库）：所有的发布应该以版本管理为起点。研发给的版本包先入版本管理工具，再从版本管理工具分发到现网发布。杜绝 rsync 一台服务器发布另外一台的做法。 资源管理和隔离工具：以xen/kvm为代表的工具让运维可以更灵活的切割资源。比如虚拟机的快速起停，ip在idc内的漂移等。以 lxc/docker 为代表的工具让运维可以进一步的切割资源到进程级别。 运维监控告警工具 采集工具：一般是采集日志文件，也可以是定时轮询 DB 或者其他系统的接口。流行的开源方案是 logstash。 收集工具：采集工具上报给收集工具。 运维事件数据库：记录所有的告警。包括从其他系统获得告警，以及对现网的所有变更操作记录。这些数据用于支撑告警的原因定位。
1.7K80发布于 2018-05-04 - 来自专栏杨建荣的学习笔记
运维开发体系升级的思考
这是学习笔记的第 2367篇文章 在大概4年前，我们算是从0到1的构建了现在的数据库运维开发体系，这个过程有较长的启动周期，从我个人主导到后来的成员独当一面，从零星的功能建设到现在有了相对体系化的建设 运维开发这件事情的理念契合，我们花了很长的时间，限于有限的资源和技术储备，我最终选择了Python技术栈，其实第1年是最让我焦虑的，这种焦虑打个比方，就好像我是司机，手里拿着方向盘，车上的乘客的心态是和我完全不同的 Python技术体系的学习和构建。 当然在这个过程中也总结了一些经验，比如对于模块化的思考，早期的OpsManage体系的构建是一个相对独立的Python服务，随着业务的接入，有了MySQL,Redis等数据库，为了对一些运维功能和技术栈有所区别 我开始构建新版本的开发环境，打算从整体设计上能够有所侧重，同时对已有的开发体系进行认真梳理和复盘。
78230发布于 2021-09-02 - 来自专栏IT大咖说
如何实现MySQL运维体系建设
内容来源：2018 年 10 月 20 日，源数据库论坛（ODF）发起人周彦伟在“ODF走进名企之贝壳技术沙龙-数据库存储技术的多元应用”进行《使用ArkControl实现MySQL运维体系建设》的演讲分享 阅读字数：2384 | 6分钟阅读 摘要 本次分享的是如何使用ARkcontrol来搭建mysql的运维体系，从功能、架构以及安装内容上来详细介绍ARkcontrol。 最终我们做了一款叫ArkControl的产品，他是一个云管平台，社区版可以免费下载使用，可以一键实现一个比较全面的mysql运维体系，不用花费太多成本就能实现一些数据库运维的基本功能，至少不用再通过命令发去安装 最左侧从主机管理到下面的审核审计这部分展示的是AkrContro能提供的功能，这些都是为了满主开发者对数据库运维的需求。 还有很重要的一块，也是今后我们发展的重点——智能运维，包括数据库的智能优化，智能的诊断和巡检。实现逐步的从人工的运维转化为智能运维，类似最优化接口或最优化配置等功能。
1.8K40发布于 2018-12-07 - 来自专栏互联网运维杂谈
运维平台规划体系全介绍
识别运维平台的边界在哪儿，才能更好的构建平台，从而协助运维的日常工作。 在之前的文章中，谈到过【运维的本质--可视化】，在可视化的篇幅中，着重介绍自动化的可视化和数据的可视化；在后续的篇章中又介绍了【互联网运维的价值体系】，里面分解了几个维度：质量、成本、效率、安全等。 找到一个价值方向来牵引整个团队很难，但又必须找到，因这个牵引力就决定了团队的气质及后续的工作方法；之前的【运维价值体系】有详述，在此不细谈。 现实中如果有研发开发了一个公共组件交给运维，而他不提供完整的webadmin或者api的话，你也就可以认为他是在耍流氓了，运维必须严格要求完整性交付。 7、数据及服务。 和之前【数据驱动运维】介绍过的，我做了一个数据的分层体系。 8、监控及服务，有数据的地方才有监控。脱离这个原则，你做的都是告警。
4.6K22发布于 2019-11-18 - 来自专栏互联网运维杂谈
谈谈我理解的运维体系
价值体系（value） 我在任何场合都在强调运维价值／IT价值和用户价值之间的关系，在精益运维的分享中，我推导过，用户价值可以通过IT价值相互转换的。 PV会减少11%，用户满意度降低16%，对话减少7%。 亚马逊网站每延长1秒的加载时间，一年就会减少16亿美元的销售额。 那Dev技术架构体系和我运维有什么关系呢？他决定了你维护成本的大与小，维护质量的高与低，维护效率的快与慢！否则，你只盯着运维平台，认为都是平台的事情。 技术标准有了，业务的碎片便没有了！ 平台体系（platform） 运维的平台体系，这个我在外面讲得很多了。 不基于产品的执行路径，大到你的运维目标设定和分解下来的roadmap，比如说运维平台体系的构建；小到你的运维流程，比如说事件流程、资源池管理流程等等。
1.6K00发布于 2019-11-20 - 来自专栏大模型
大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手
直达原文：大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手背景1、运维转型背景蓝鲸平台从诞生之初，就一直在不遗余力地推动运维转型，让运维团队可以通过一体化 PaaS 平台，快速编写脚本，编排流程，开发运维工具 2、大模型对运维开发带来的挑战和机遇最近几年，大模型的爆发式发展为开发和运维行业带来新的变革，2021 年 7 月 1 日，由 GitHub 和 OpenAI 共同开发的人工智能编码助手——Copilot 而且，通义灵码的工作节奏比 996 还要极致：7x24 小时随叫随到......看起来，大模型的应用似乎要终结开发框架、低代码这类脚手架开发工具。难道，运维不再需要开发转型了？ 技术架构上，通过 RAG + Embedding 技术，可以海量的运维知识（截至 2023 年 12 月，嘉为知识库存量文档 394035 篇，月均消费 7 万+次）向量化存储，作为大模型的外挂知识库， 直达原文：大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手
1.3K01编辑于 2024-05-27 大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手
本文来自腾讯蓝鲸智云社区用户: CanWay背景1、运维转型背景蓝鲸平台从诞生之初，就一直在不遗余力地推动运维转型，让运维团队可以通过一体化PaaS平台，快速编写脚本，编排流程，开发运维工具，从被动地提供运维支撑服务 为了让运维人员更快成长为“六边形运维”（参考《在线跟腾讯工程师学习SaaS开发》，泛指运维界的六边形战士，特指掌握了运维开发技能的运维人群），降低运维开发 SaaS 的难度，蓝鲸不仅提供了蓝鲸开发框架， 2、大模型对运维开发带来的挑战和机遇最近几年，大模型的爆发式发展为开发和运维行业带来新的变革，2021 年 7 月 1 日，由 GitHub 和 OpenAI 共同开发的人工智能编码助手——Copilot 而且，通义灵码的工作节奏比996还要极致：7x24小时随叫随到…看起来，大模型的应用似乎要终结开发框架、低代码这类脚手架开发工具。难道，运维不再需要开发转型了？甚至“零运维”在AI的帮助下提前实现了？ 技术架构上，通过 RAG + Embedding 技术，可以海量的运维知识（截至2023年12月，嘉为知识库存量文档394035篇，月均消费7万+次）向量化存储，作为大模型的外挂知识库，利用大模型强大的总结能力
1.2K10编辑于 2024-11-13- 来自专栏互联网运维杂谈
水平｜运维产品的能力闭环体系
实现一个运维产品的闭环，比碎片式的产品建设更有意义。 抛开我最近创业对这一问题的必要性思考，回归到一个企业内运维团队本身，个人觉得也需要思考这个命题。一个完善的运维平台才能做到对业务的运营有效支撑。 但随着后面应用运维的运维平台的一体化能力不断增强（比如说腾讯织云／蓝鲸），此时就对底层的运维平台能力开放性要求越来越高。 当然这个地方我建议分成如下三个阶段： 1、独立的按照核心角色需求建设运维平台。 以上的域名能构成一个全自动化平台的能力体系。 5、监控域。 7、运营分析。它不能构成一个域，只能称为一种场景。基于很多运营场景，场景化的数据分析和应用，通过数据来驱动运维优化，类似运营商的经营分析系统。 8、用户域。 精细化／实时／端到端的数据采集／处理／分析体系是运营价值的核心部分。 坚持产品的垂直与水平闭环体系，才是一个做出一个真正好用的运维平台！
2K00发布于 2019-11-19 - 来自专栏运维经验分享
CentOS 7 运维优化 原
CentOS 7 运维优化 一般的，我们安装CentOS mini和其他相应服务后，就能正常工作了。但工作一段时间后，服务器会出现不稳定、被入侵、甚至在突然的高并发时直接瘫痪状况。 所以，在这里提供一些运维优化的建议。 1.关闭不需要的服务 众所周知，服务越少，系统占用的资源就会越少， 所以应当关闭不需要的服务。 "$tty" = "$X_TTY" ] && continue initctl start tty TTY=$tty done end script 1 2 3 4 5 6 7 echo "IPV6INIT=no" >> /etc/sysconfig/network-scripts/ifcfg-eth0 # 禁用基于IPv6网络，使之不会被触发启动 1 2 3 4 5 6 7 8 7.调整 Linux 的最大文件打开数 要调整一下 Linux 的最大文件打开数，否则运行 Squid 诅服务的机器在高负载时执行性能将会很差；另外，在 Linux 下部署应用时，有时候会遇上 “
2.8K20发布于 2019-03-11 - 来自专栏devops_k8s
自动化运维体系如何入手
1 需求 运维是事件驱动，还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障，而自驱动让运维不止于建设。 持续性的运维建设就需要一套自动化的运维体系，那么我们应该从何入手？ 其实前期《运维思考》一系列文章已经给我们答案了，就是从运维框架入手分层建设、打好基础，记住“万丈高楼平地起，勿在浮沙筑高台”。 3 运维依据如果你觉得运维框架还不够细致，那么针对框架中各个层次的工作拆解就来了，我们在此将其称之为运维依据。 4 小结 通过以上各个层面的运维框架和运维依据，希望大家能够结合实际情况进行头脑风暴，做到不止于此。 当然自动化运维建设不是一蹴而就的，需要结合规范、制度、流程去逐步实现。
1.1K30编辑于 2023-07-21 - 来自专栏互联网运维杂谈
初探精益运维体系｜多图
有一种努力一直放在心中，想更系统的表现运维，内心的这份冲动源于两点： 1.在互联网化业务的今天，运维的作用可以被更重视。 2.运维需要更体系化，更理论化，更实践化的阐述。 在之前，我用过价值化运维来概括过运维，我也多次在文章中或公开演讲中提到运维应该关注“面向用户的价值“，但我依然觉得还是不够精炼。 直到后来想到了“精益“这个词，把它和运维做了一次融合，只因精益思想的背后，很多观点都和我们运维很契合。接下来看看我在《全球运维大会｜上海站》上分享的主题——面向高性能IT的精益运维体系。 精益运维团队也需要有“精益”的气质，里面有对一线运维人员的经验和价值的尊重和重视；内建价值体系，仅仅质量体系还不够，分质量／成本／效率／安全等等。 ? 如何达到精益运维，这个时候需要一些标准实践。 比如说自动化一切／持续交付；运维和线上服务的度量；端到端监控；标准化，无论是业务的标准化还是工具的标准化等等。 这只是一个初步的精益运维体系框架，还有很多内容值得细化和深入。
2.1K10发布于 2019-11-18 - 来自专栏博文视点Broadview
高屋建瓴地规划自己的运维体系
运维要做的事情与岗位职责内容密切联系，可能有了运维要做的事情需求，因此设置了岗位和人员，但也有因为有了这个岗位的人，因此创造了一些运维事情。 这有点“鸡生蛋、蛋生鸡”的逻辑。 1 运维系统架构 每个公司的IT 环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。 这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且设备性能指标往往非常好，例如一台普通中端的Power 7 系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。 去IOE 过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。因此如果贸然去IOE，可能既不会降低成本，也不会提高效率，更不会稳定架构。 自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。 是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。
1K10发布于 2020-06-11 - 来自专栏互联网运维杂谈
垂直｜运维产品的能力分层体系
一个好的运维产品分层体系，是运维平台理解清晰与否的标志。 建设一个完整的运维平台，绝非一日之功，也非一两个平台所能覆盖，因此我非常喜欢用分层体系来归纳问题。 无论是整体运维产品的规划体系，还是自动化体系，还是数据化体系，甚至说CMDB平台的资源体系，都可以用分层归纳总结。以下是我对运维产品整体分层体系的理解： ? 该能力在依赖平台的同时，更依赖的是运维团队的业务理解能力和经验总结。 这一层的能力都表现为一个具体的产品形式＋运营方法，从而确保能够很好的闭环起来。 ；是基于角色的，而非基于单一用户的－－运维的角色能过清晰定义场景需求，用户的需求往往是片面而不真实的需求；基于事务的，而非基于职能的－－事务能过跨越职能组，让运维组织的自动化和数据能力流动起来； 平台能力是指基于底层平台构建起来的运维自动化 通用能力层 通用能力层是基于基础设施之上封装的公共服务能力，这层架构的能力分成两部分：一部分是面向业务技术架构的，另一部分是面向运维服务架构的。
2K11发布于 2019-11-19 运维管理平台化：运维体系为什么要基于平台化建设
运维平台的概念被泛化近几年行业发展和客户实践，运维体系和运维架构得到蓬勃的发展，各种概念和实践层出不穷，而关于运维平台，主流声音和理解有几种：平台工程平台工程是Gartner发布2023年十大战略技术趋势 SRE体系SRE是一套旨在通过软件工程的方式提高应用可靠性的体系，用软件工程的管理和技术方法来解决运维问题的体系，其中特别强调主动管理和规避风险，包括如运维工作限制在50%以内、面向不确定性来设计、尽可能的自动化和简单化 为了更好地实践，国内通常会选择基于可支持运维开发的运维平台，以此来迅速构建运维系统的软件工程能力。虽然这与运维的平台化有所重合，但并未深入探讨SRE体系与平台之间的关联。 ，以及和业务域关联集成设计组成，因而运维管理抽象成运维业务，是工具体系建设的起点，而工具体系是承接运维业务和运维管理落地的一种能力。 这也是很多企业发现构建了监管控的基本运维系统体系，但实质的运维活动没有很好的改进和变化的原因。
1.6K10编辑于 2024-07-30- 来自专栏织云平台团队的专栏
GOPS2018--腾讯运维体系专场回顾
当然是GOPS全球运维大会--腾讯运维体系专场了，几位老师给大家带来了一场思想盛宴。活动圆满结束！～ ? 下面跟着小编来去看看活动现场盛况，感受几位讲师的风（yan）采(zhi)吧。 ? 首先，让我们隆重地请出本次专场活动的出品人兼主持人--腾讯运维总监聂鑫，从开发到运维，伴随社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作，见证了整个SNG运维体系的建立，发展和成熟过程。 分享主题是《社交业务运维基础技术架构选型与演进》。演讲回溯了10多年的运维变化，从运维响应社交业务迸发开始，到运维满足业务需求同时并且切入主线做标准化。 运维基础技术持续演进，自动化能力提升，业务高效调度实现，最终实现支撑一人万台运维，高效自动化运维先进体系搭建，以及AIOps能力。小编在台下听到有人夸赞老师有深邃的眼神，嗯，我去私信转达一下老师。 最后，由数学博士张戎压轴，带来《腾讯运维场景的 AI 实践》，结合QQ的运维场景，介绍在日常的运维方面，如何使用机器学习的算法来实现智能运维。
2.2K110发布于 2018-04-17 - 来自专栏互联网运维杂谈
运维的目标价值体系
运维价值的提炼，直接决定了团队（个人）对运维理解的高度和精度！ 从很多传统的视角去看运维，运维的确承担了很多职能，但这些职能还是都和具体的岗位相关，如下： ? 具体的个人理解如下： 一、质量(Quality) 我们还需要从经典的质量定义开始，用【层次分析法】逐渐打开，去认识质量体系的全貌。 数据要建立分级体系，不同的数据分级需要有不同的管理策略和数据使用策略，这些策略包含访问密码加密、访问日志的脱敏、数据隔离访问、数据加密、数据的备份、数据的加密获取等等。 在后续会推出一系列的文章来多角度，多层次的来看运维，提前给出如下（排名不分先后）： 1、【平台篇】平台建设规划总体系介绍 讲讲我规划的几个运维平台体系。 7、【平台篇】持续集成之持续部署建设 基于持续集成理论的持续部署如何实现的？ 8、【理论篇】DevOps到底给运维带来了什么变化？
3.6K11发布于 2019-11-18
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号