- 综合排序
- 最热优先
- 最新优先
- 来自专栏互联网老辛
运维所需技能体系
而运维在这个生命周期中的每个阶段都有可能参与： 设计阶段： 主要针对系统架构设计的合理性进行评估，包括是否存在单点，是否可以容错，是否有强耦合等。 通过运维的基本工作，我们来看看一个运维人员需要掌握的知识体系： 操作系统： 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 IPMI IPMI， CMDB 需求分析，IDC选型，网络测试，谈价格，签合同，设备采购（原厂vs渠道）、机柜和机位规划 巡检，IPMI IPMI， CMDB 数据中心选址、制冷、供电、网络、运维 运维管理体系 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年是最让我焦虑的，这种焦虑打个比方，就好像我是司机，手里拿着方向盘，车上的乘客的心态是和我完全不同的 当然在这个过程中也总结了一些经验，比如对于模块化的思考，早期的OpsManage体系的构建是一个相对独立的Python服务，随着业务的接入，有了MySQL,Redis等数据库，为了对一些运维功能和技术栈有所区别 现在的技术栈情况如下： 操作系统 CentOS6.8 VirtualBox5.1 Pycharm 早期版本 Python 2.7.6 Django 1.7版本 MySQL 5.7 Redis 3 规划后打算采用的技术栈 整体的步调如下： 1）梳理现有Python 2.7技术栈的代码情况 2）第一次瘦身在现有Python 2.7的基础上完成，删除荣誉的代码模块和页面 3）完成新一版本的模型设计 4）新版本的模型设计在新环境中构建测试
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 - 来自专栏互联网运维杂谈
运维平台规划体系全介绍
在之前的文章中，谈到过【运维的本质--可视化】，在可视化的篇幅中，着重介绍自动化的可视化和数据的可视化；在后续的篇章中又介绍了【互联网运维的价值体系】，里面分解了几个维度：质量、成本、效率、安全等。 找到一个价值方向来牵引整个团队很难，但又必须找到，因这个牵引力就决定了团队的气质及后续的工作方法；之前的【运维价值体系】有详述，在此不细谈。 3、配置及服务，把配置当作服务来看待。 和之前【数据驱动运维】介绍过的，我做了一个数据的分层体系。 8、监控及服务，有数据的地方才有监控。脱离这个原则，你做的都是告警。 3、平台建设先后有序，优先级顺序如下： P1(最高）：CMDB、基础架构及服务、数据及服务、监控及服务 P2(次高）：持续集成、面向业务的运维平台 P3(低)：ITIL相关、运维统一门户 以上所有供参考和讨论
4.6K22发布于 2019-11-18 - 来自专栏互联网运维杂谈
谈谈我理解的运维体系
价值体系（value） 我在任何场合都在强调运维价值／IT价值和用户价值之间的关系，在精益运维的分享中，我推导过，用户价值可以通过IT价值相互转换的。 来自以下的统计数据： 网页速度加载超过3秒，会损失超过57%的用户，57%的用户在3秒后还没有加载完，就会离开，除非原因是她的电脑问题或网速问题。 那Dev技术架构体系和我运维有什么关系呢？他决定了你维护成本的大与小，维护质量的高与低，维护效率的快与慢！否则，你只盯着运维平台，认为都是平台的事情。 技术标准有了，业务的碎片便没有了！ 平台体系（platform） 运维的平台体系，这个我在外面讲得很多了。 不基于产品的执行路径，大到你的运维目标设定和分解下来的roadmap，比如说运维平台体系的构建；小到你的运维流程，比如说事件流程、资源池管理流程等等。
1.6K00发布于 2019-11-20 - 来自专栏大模型
大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手
直达原文：大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手背景1、运维转型背景蓝鲸平台从诞生之初，就一直在不遗余力地推动运维转型，让运维团队可以通过一体化 PaaS 平台，快速编写脚本，编排流程，开发运维工具 为了让运维人员更快成长为“六边形运维”（参考《在线跟腾讯工程师学习 SaaS 开发》，泛指运维界的六边形战士，特指掌握了运维开发技能的运维人群），降低运维开发 SaaS 的难度，蓝鲸不仅提供了蓝鲸开发框架 3、语言创作大模型能够根据输入的上下文信息生成连贯、流畅的文本，例如撰写文章、生成对话、创作诗歌或故事等。 3、专业知识问答大模型天然在自然语言理解和知识总结有巨大的优势，而嘉为蓝鲸又有上千家各行各业的企业运维解决方案实施经验，积累了海量的运维开发领域专业知识。 直达原文：大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手
1.3K01编辑于 2024-05-27 大模型在蓝鲸运维体系应用——蓝鲸运维开发智能助手
本文来自腾讯蓝鲸智云社区用户: CanWay背景1、运维转型背景蓝鲸平台从诞生之初，就一直在不遗余力地推动运维转型，让运维团队可以通过一体化PaaS平台，快速编写脚本，编排流程，开发运维工具，从被动地提供运维支撑服务 为了让运维人员更快成长为“六边形运维”（参考《在线跟腾讯工程师学习SaaS开发》，泛指运维界的六边形战士，特指掌握了运维开发技能的运维人群），降低运维开发 SaaS 的难度，蓝鲸不仅提供了蓝鲸开发框架， 3、语言创作大模型能够根据输入的上下文信息生成连贯、流畅的文本，例如撰写文章、生成对话、创作诗歌或故事等。 3、专业知识问答大模型天然在自然语言理解和知识总结有巨大的优势，而嘉为蓝鲸又有上千家各行各业的企业运维解决方案实施经验，积累了海量的运维开发领域专业知识。 ，经过 Prompt 优化后发送到大模型；3.大模型返回SQL语句，用户复制或插入到平台中。
1.2K10编辑于 2024-11-13- 来自专栏互联网运维杂谈
水平｜运维产品的能力闭环体系
但随着后面应用运维的运维平台的一体化能力不断增强（比如说腾讯织云／蓝鲸），此时就对底层的运维平台能力开放性要求越来越高。 当然这个地方我建议分成如下三个阶段： 1、独立的按照核心角色需求建设运维平台。 3、某些场景开放给应用运维平台自动化处理，即API化。第二个阶段运行逐渐成熟之后，最重要的是理念已经达成一致，此时可以考虑能力API开放，控制好接口的权限。 3、运维服务域。资源及服务资源的管理都需要抽象成服务，服务化的管理能力以平台化／可视化管理为基础的。 以上的域名能构成一个全自动化平台的能力体系。 5、监控域。 精细化／实时／端到端的数据采集／处理／分析体系是运营价值的核心部分。 坚持产品的垂直与水平闭环体系，才是一个做出一个真正好用的运维平台！
2K00发布于 2019-11-19 - 来自专栏devops_k8s
自动化运维体系如何入手
1 需求 运维是事件驱动，还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障，而自驱动让运维不止于建设。 持续性的运维建设就需要一套自动化的运维体系，那么我们应该从何入手？ 其实前期《运维思考》一系列文章已经给我们答案了，就是从运维框架入手分层建设、打好基础，记住“万丈高楼平地起，勿在浮沙筑高台”。 3 运维依据如果你觉得运维框架还不够细致，那么针对框架中各个层次的工作拆解就来了，我们在此将其称之为运维依据。 4 小结 通过以上各个层面的运维框架和运维依据，希望大家能够结合实际情况进行头脑风暴，做到不止于此。 当然自动化运维建设不是一蹴而就的，需要结合规范、制度、流程去逐步实现。
1.1K30编辑于 2023-07-21 - 来自专栏互联网运维杂谈
初探精益运维体系｜多图
有一种努力一直放在心中，想更系统的表现运维，内心的这份冲动源于两点： 1.在互联网化业务的今天，运维的作用可以被更重视。 2.运维需要更体系化，更理论化，更实践化的阐述。 在之前，我用过价值化运维来概括过运维，我也多次在文章中或公开演讲中提到运维应该关注“面向用户的价值“，但我依然觉得还是不够精炼。 直到后来想到了“精益“这个词，把它和运维做了一次融合，只因精益思想的背后，很多观点都和我们运维很契合。接下来看看我在《全球运维大会｜上海站》上分享的主题——面向高性能IT的精益运维体系。 精益运维团队也需要有“精益”的气质，里面有对一线运维人员的经验和价值的尊重和重视；内建价值体系，仅仅质量体系还不够，分质量／成本／效率／安全等等。 ? 如何达到精益运维，这个时候需要一些标准实践。 比如说自动化一切／持续交付；运维和线上服务的度量；端到端监控；标准化，无论是业务的标准化还是工具的标准化等等。 这只是一个初步的精益运维体系框架，还有很多内容值得细化和深入。
2.1K10发布于 2019-11-18 - 来自专栏博文视点Broadview
高屋建瓴地规划自己的运维体系
运维要做的事情与岗位职责内容密切联系，可能有了运维要做的事情需求，因此设置了岗位和人员，但也有因为有了这个岗位的人，因此创造了一些运维事情。 这有点“鸡生蛋、蛋生鸡”的逻辑。 1 运维系统架构 每个公司的IT 环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。 去IOE 过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。因此如果贸然去IOE，可能既不会降低成本，也不会提高效率，更不会稳定架构。 自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。 是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。 做好日常基础运维工作，保障好生产业务运行。不断探索新的运维理念与技术，探索优化系统架构。最重要的是要运维明白什么是正确的事，怎么正确地做事，做事有章法，才能实现稳定高效能。
1K10发布于 2020-06-11 - 来自专栏互联网运维杂谈
垂直｜运维产品的能力分层体系
一个好的运维产品分层体系，是运维平台理解清晰与否的标志。 建设一个完整的运维平台，绝非一日之功，也非一两个平台所能覆盖，因此我非常喜欢用分层体系来归纳问题。 无论是整体运维产品的规划体系，还是自动化体系，还是数据化体系，甚至说CMDB平台的资源体系，都可以用分层归纳总结。以下是我对运维产品整体分层体系的理解： ? 该能力在依赖平台的同时，更依赖的是运维团队的业务理解能力和经验总结。 这一层的能力都表现为一个具体的产品形式＋运营方法，从而确保能够很好的闭环起来。 ；是基于角色的，而非基于单一用户的－－运维的角色能过清晰定义场景需求，用户的需求往往是片面而不真实的需求；基于事务的，而非基于职能的－－事务能过跨越职能组，让运维组织的自动化和数据能力流动起来； 平台能力是指基于底层平台构建起来的运维自动化 通用能力层 通用能力层是基于基础设施之上封装的公共服务能力，这层架构的能力分成两部分：一部分是面向业务技术架构的，另一部分是面向运维服务架构的。
2K11发布于 2019-11-19 - 来自专栏kafka专栏
3.【kafka运维】Topic的生产和发送运维脚本(3)
Topic的消费kafka-console-consumer.sh More 日常运维 、问题排查 怎么能够少了滴滴开源的 滴滴开源LogiKM一站式Kafka监控与管控平台 1.Topic的发送 默认值) –max-partition-memory-bytes Long 为分区分配的缓冲区大小 16384 –message-send-max-retries Integer 最大的重试发送次数 3 bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --whitelist ‘.*’ --from-beginning 3. kafka.tools.NoOpMessageFormatter、kafka.tools.ChecksumMessageFormatter More Kafka专栏持续更新中…(源码、原理、实战、运维
72220发布于 2021-08-03 运维管理平台化：运维体系为什么要基于平台化建设
SRE体系SRE是一套旨在通过软件工程的方式提高应用可靠性的体系，用软件工程的管理和技术方法来解决运维问题的体系，其中特别强调主动管理和规避风险，包括如运维工作限制在50%以内、面向不确定性来设计、尽可能的自动化和简单化 为了更好地实践，国内通常会选择基于可支持运维开发的运维平台，以此来迅速构建运维系统的软件工程能力。虽然这与运维的平台化有所重合，但并未深入探讨SRE体系与平台之间的关联。 ，以及和业务域关联集成设计组成，因而运维管理抽象成运维业务，是工具体系建设的起点，而工具体系是承接运维业务和运维管理落地的一种能力。 这也是很多企业发现构建了监管控的基本运维系统体系，但实质的运维活动没有很好的改进和变化的原因。 3、数据与AI、大语言模型、可观测等领域技术发展，运维平台的定义是否还存在？架构上如何支撑新的扩展场景？
1.6K10编辑于 2024-07-30- 来自专栏织云平台团队的专栏
GOPS2018--腾讯运维体系专场回顾
当然是GOPS全球运维大会--腾讯运维体系专场了，几位老师给大家带来了一场思想盛宴。活动圆满结束！～ ? 下面跟着小编来去看看活动现场盛况，感受几位讲师的风（yan）采(zhi)吧。 ? 首先，让我们隆重地请出本次专场活动的出品人兼主持人--腾讯运维总监聂鑫，从开发到运维，伴随社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作，见证了整个SNG运维体系的建立，发展和成熟过程。 分享主题是《社交业务运维基础技术架构选型与演进》。演讲回溯了10多年的运维变化，从运维响应社交业务迸发开始，到运维满足业务需求同时并且切入主线做标准化。 运维基础技术持续演进，自动化能力提升，业务高效调度实现，最终实现支撑一人万台运维，高效自动化运维先进体系搭建，以及AIOps能力。小编在台下听到有人夸赞老师有深邃的眼神，嗯，我去私信转达一下老师。 最后，由数学博士张戎压轴，带来《腾讯运维场景的 AI 实践》，结合QQ的运维场景，介绍在日常的运维方面，如何使用机器学习的算法来实现智能运维。
2.2K110发布于 2018-04-17 - 来自专栏互联网运维杂谈
运维的目标价值体系
运维价值的提炼，直接决定了团队（个人）对运维理解的高度和精度！ 从很多传统的视角去看运维，运维的确承担了很多职能，但这些职能还是都和具体的岗位相关，如下： ? 具体的个人理解如下： 一、质量(Quality) 我们还需要从经典的质量定义开始，用【层次分析法】逐渐打开，去认识质量体系的全貌。 这个地方记得控制指标不宜过多，最好控制在3个左右，过多的指标会让最终的质量数据波动太大，从而不能更好的牵引优化团队向前，也可以A阶段用A指标，等A优化完成后，在B阶段再纳入另外一个指标。 在后续会推出一系列的文章来多角度，多层次的来看运维，提前给出如下（排名不分先后）： 1、【平台篇】平台建设规划总体系介绍 讲讲我规划的几个运维平台体系。 3、【平台篇】运维系统之监控系统建设 你认为你做的是监控系统，其实你做的是一个告警系统。真正的监控系统要解决的核心问题是什么？秀架构、秀大数据处理的监控平台是不是一个好的监控平台？
3.6K11发布于 2019-11-18
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号