备注:我把标准化当做运维的基础,它对运维平台及数据平台有着重要的影响。 对于应用运维来说,标准化是有方法和套路的,首先是这个标准化一定是运维主导的,不是研发主导,生产环境在你手,是需要把生产环境的可运维性为标准的;其次标准化的东西很多,这个就看运维人思考的边界在哪儿? 我们做这么多的标准化,不就是为了让大家一眼就能看得明白,基于它们构造的运维能力,人人可以对接。 标准化以简化运维平台建设为度量。 除了早期的一些流程,对线上的所有标准化,都可以理解成是为了简化运维平台建设,这些规范必须沉淀到平台中,才能真正做到方便运维。 标准化是有层次的。硬件、OS、应用、协议.....。 标准化意味着运维理解的精确度。可以自己体会一下,你不会觉得运维无事可做,或者就是提供服务器的。
但是如何建设自动化运维,在不同的企业有着不同的建设方法和技术栈,虽然大多是以Python为主。一般说来,企业的运维发展由起步到成熟,大致要经过三个大阶段:运维无序化、运维标准化和流程化、运维自动化。 什么是运维标准化和流程化呢?如果非要给出定义的话,那么我的定义是两个字:文档。 运维的标准化和流程化首先要以文档的形式进行展示,并且能够指导日常运维工作。 国有国法,家有家规,冰箱洗衣机都有说明书,运维标准化流程化就是运维工作的国法家规,运维工作如何进行的说明书。 并且运维自动化的落地实施也是要基于运维的标准化和流程化,所以作为运维管理的第一步,不可忽略。 最后,标准化和流程化是最运维自动化最基础准备。 ●加快运维自动化的建立。
一、问题回顾 接上篇《运维架构是全站技术架构中不可分割的一部分》,文中提到一个问题,运维架构和技术架构的脱节这个问题到底出在哪了?到底谁应该承担这个责任? 三、架构契约中的运维部分—架构标准化 上面提到的团队和团队协作,这个就不多说了,组织定期的例会讨论,多参加彼此技术方案会议,随时随地的交流,这个只要保持开放的心态和合作模式都是可以做到的。 还是想再说一下,千万不要出现,开发说这个应该是运维考虑的事情,跟我们无关,运维说这个应该是开发的事情,开发想不不清楚让我们怎么办? 重点谈谈关于架构标准化,之前提到的标准,更多的还是偏运维层面的标准,比如硬件资源标准、应用标准、部署标准等,这些在《如何打造一个以应用为核心的运维体系》文章介绍过,不多解释。 上篇讲了技术架构与运维脱节的问题,这篇算是进了一步,运维真正的参与到了架构设计中,确切说是架构标准制定中,运维虽然不是架构的实现者和开发者,但确是维护架构统一和标准的执行者。
点击立即体验WeOps众所周知容器(docker)是一艘航行在IT大海里的“轮船”为了驶向彼岸,需要一个“船舵”(K8S)那如何更好更快地前行呢? 你需要“We Operations”统一管理,让船上的“货物”井井有条统一监控,“货物”故障提前感知,更快解决问题下面正式介绍多才多艺的:嘉为蓝鲸一体化运维平台WeOps! 成熟稳定腾讯每年3亿重金打造+超10年持续迭代+支撑30w节点运维实践,构建成熟稳定的运维平台。轻量部署轻量化,支持单机部署,20+年专家经验沉淀+10万用户的市场验证,内置场景,一键启用。
k8s常用命令 node 查看服务器节点 kubectl get nodes 查看服务器节点详情 kubectl get nodes -o wide 节点打标签 kubectl label nodes pods --all-namespaces #查看具体pods,记得后边跟namespace名字哦 kubectl get pods kubernetes-dashboard-76479d66bb-nj8wr --namespace=kube- system 查看pods具体信息 kubectl get pods -o wide kubernetes-dashboard-76479d66bb-nj8wr - kubectl api-versions # API kubectl get events # 查看事件 kubectl get nodes //获取全部节点 kubectl delete node k8s2 # 标记 my-node 不可调度 kubectl drain k8s-node # 清空 my-node 以待维护 kubectl uncordon k8s-node # 标记 my-node 可调度
云平台的研发和运维人员可以通过软件源管理系统快速搭建和维护 YUM、APT 等软件源,以便满足研发和运维人员在环境搭建、开发、构建、测试、运行等环节的组件和工具依赖需求,提升整体研发和运维效能。 历史记录 用于运维人员查看指定软件源的同步操作事件,便于判断软件源的整体工作状态。 操作记录 用于运维人员或者审计人员来查看指定软件源的操作记录(新建、修改和删除)。 这也是我们运维专题的最后一期了,小编这里将系列专题做个汇总,方便大家系统的回顾云运维,如:统一配置信息管理的CMDB、监控告警自动化的云哨系统、混沌工程故障演练平台等等: 第一期 运维专题第一期:数据中枢 第二期 运维专题第二期:警戒哨兵 第三期 运维专题第三期:诊断专家 第四期 运维平台第四期:数据掘金者 第五期 运维平台第五期:业务永续 第六期 运维平台第六期:混沌工程,助力系统稳如磐石 第七期 运维专题第七期:云上保险柜 第八期 运维专题第八期:软件源 古人云:学无先后,达者为师,在写这一系列推文的时候,所有的产品经理就好似上学时的老师一样,教授给小编相关的知识以及经验,让小编不自觉的就想起了以前上学时恩师的谆谆教诲
什么是k8s? k8s是kubernetes的简称,即字母“k”到最后一位相隔8位字母。名字来源于希腊语,意思是“舵手”或“领航员”。 设置远程登录root账户 vim /etc/ssh/sshd_config 增加一行 PermitRootLogin yes 重启服务 service ssh restart 关闭交换空间(k8s 192.168.17.129:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:6a051b8d0b670f357fe0d8e6a282b062b6f090d1b90968d6c3f3cea8dd33d104
多关注软件可能暴露的一些安全问题,或者linux本身的系统问题 说不定谋个nginx版本突然说有问题,你还没关注到,那就很容易被黑掉 8.网络问题,很多时候都是这样,某个地方访问慢,但其他人访问不慢 8.监控很重要,可以查看流量,某些服务使用内存是否超标,没有监控出了事都不知道,监控不仅要监控服务的端口防止挂掉,还要他深度的使用,比如mysql的慢查询,命中率,主从状态等等。 (8)基础服务建设 业务对DNS、NTP、SYSLOG等基础服务的依赖非常高,需要设计高可用架构避免单点,提供稳定的基础服务。 运维研发 运维研发负责通用的运维平台设计和研发工作,如:资产管理、监控系统、运维平台、数据权限管理系统等。提供各种API供运维或研发人员使用,封装更高层的自动化运维系统。详细的工作职责如下所述。 ,处理值班问题,确保系统服务稳定性; 负责运维自动化/标准化方案设计,自动化工具及平台研发,提升运维效率; 负责生产、测试、灰度多套环境的部署和维护,配合研发、测试团队进行应用部署;
而运维的管理实践中充斥着大量重复性事物,并且是批量级别的运维任务,在这种情况下运维的标准化就工作就显得至关重要了。 通过运维的标准化,可以实现对“运维最佳实践”的归纳和总结,从而实现对“运维最佳实践”的统一规范和执行。 所以标准化是提高团队效率的重要方式,是梳理运维杂乱问题的重要依据。 运维标准化之核心原则 1. 结束语 笔者希望通过这篇文章能向各位传达一个观点,企业运维的标准化其实很简单。 不用追求大而全,从自己的最佳实践出发,统一化规范化以后,会发现运维的工作突然清晰了很多,以前宣扬的“运维是神仙干的活”也不过如此。 以标准化为起点,我们可以到运维架构化,到运维服务化,再到运维自动化。 因此,标准化可以说是运维的起点工作。 以上便是我在运维标准化学习实践的一些总结,现在做的还不是很成功,还在继续努力中。
/storage/k8s/es 2)创建NFS的rbac [root@k8s-master01 k8s_project]# cd [root@k8s-master01 ~]# cd /opt/k8s/k8s_project / [root@k8s-master01 k8s_project]# mkdir elk [root@k8s-master01 k8s_project]# cd elk/ [root@k8s-master01 1)创建es集群的storage [root@k8s-master01 elk]# pwd /opt/k8s/k8s_project/elk [root@k8s-master01 elk]# mkdir [root@k8s-master01 images]# pwd /opt/k8s/k8s_project/elk/es/images [root@k8s-master01 images]# ll total [root@k8s-master01 es]# pwd /opt/k8s/k8s_project/elk/es [root@k8s-master01 es]# mkdir deploy/ [root@k8s-master01
上面都是一些显而易见的道理,但是从显而易见或司空见惯的事物中挖掘出营养却是一个非常值得努力的方向 因为这些司空见惯的的事物太多了,但我们未必真懂得其中的内涵或蕴藏的智慧,哪怕只深掘一层,将会发现遍地都是宝藏 作为运维
作为快速入门Kafka系列的第八篇博客,本篇为大家带来的是kafka监控及运维~ 码字不易,先赞后看! ? ---- Kafka监控及运维 在开发工作中,消费在Kafka集群中消息,数据变化是我们关注的问题,当业务前提不复杂时,我们可以使用Kafka 命令提供带有Zookeeper客户端工具的工具 useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull #kafka.eagle.username=root
Linux运维工程师面试题(8)祝各位小伙伴们早日找到自己心仪的工作。持续学习才不会被淘汰。地球不爆炸,我们不放假。机会总是留给有有准备的人的。加油,打工人! 8 制作镜像方式docker commit # 通过修改现有容器,将之手动构建为镜像docker build # 通过Dockerfile文件,批量构建为镜像9 K8S 有那些组件,都是干什么用的 10 K8S 创建一个pod的流程准备好对应的yaml文件,通过kubectl发送到Api Server中;Api Server接收到客户端的请求将请求内容保存到etcd中;Scheduler会监测etcd 阿里云、腾讯云、华为云、今日头条、百家号、GitHub、个人博客公众号:阿贤Linux个人博客:blog.waluna.tophttps://blog.waluna.top/---原文链接: Linux运维工程师面试题 (8).
// MongoDB运维与开发(8)---MongoDB备份与恢复 // 任何数据库都离不开日常的备份与恢复,这二者是数据库安全的前提,MongoDB的备份与恢复方法一般而言都采用自带的工具来进行
运维人别硬扛了!看AI怎么帮你流程标准化又快又稳在运维圈子里流传一句至理名言:“人是最不稳定的风险源。” 做久了运维你就知道,出问题往往不是系统多烂,而是流程没标准,操作靠心情。 今天,咱们来聊点硬核又接地气的话题——人工智能在运维流程标准化中的应用。 一句话总结:别再靠拍脑袋搞运维了,让AI来帮你抠细节、兜底线、提效率。一、为啥运维流程总是“不标准”? 二、人工智能,怎么帮运维标准化?AI在运维里不是干掉人,而是标准化人的经验和套路。 尤其是随着AIOps平台(像腾讯蓝鲸、阿里智维等)越来越成熟, AI+运维流程标准化,已经是大势所趋。六、最后敲重点未来,真正牛的运维不是手速快,而是能让系统自己动起来。 人不该再陷在无休止的手动工单、重复故障、疲劳战斗里,而应该把精力放在:定义标准 优化流程 训练AI系统一句话总结:AI不是让运维失业,而是让运维更值钱。标准化,是走向智能运维的必经之路。
运维效率低下,故障排查耗时耗力当终端出现故障时,IT运维人员往往需要逐台现场排查或远程连接处理。面对成百上千台终端,这种"救火式"运维模式不仅响应速度慢,更难以形成系统化的故障知识库。 远程运维赋能:提升响应效率与用户体验高效的桌面管理离不开远程运维能力的支撑。 此外,远程运维过程中的所有操作均被完整记录,形成可追溯的审计日志。这不仅满足了等保2.0及ISO 27001等合规要求,也为后续的安全事件调查提供了关键证据链。 理想的技术架构应具备以下特征:统一Agent架构:在终端部署轻量级客户端,实现配置管理、软件管控、远程运维、资产盘点等能力的模块化集成,避免多Agent冲突导致的系统性能损耗。 通过构建标准化的桌面管理体系,企业不仅能够将安全基线落实到每一台终端,更能将IT运维团队从重复的"救火"工作中解放出来,聚焦于更具价值的战略性任务。
来源:运维人那些事儿 ID:jzjytd2016 【01】换工作 2017年8月份的某一个晴朗慵懒的下午,我在望京中环南路7号西家大院E楼5层最角落且紧靠大落地窗的工位上掐指一算,我在研究院竟然已经工作 顶着小伙伴和家人都觉得你脑子进水的诧异目光,我开始了我的换工作大业,从实习开始就在研究院工作,突然开始可以选择了竟然有些茫然,种种纠结波折暂且不表,总之,在2017年12月18号,我走进了东四157号,正式成为了银河信息化集中交易运维团队的一份子 每每想到这些,我除了自责、懊恼、自我怀疑之外,也深深体会到了团队成员的团结和大家释放出来的善意,对于运维团队来讲,每天来自业务部门及客户的压力非常大,小心翼翼,如履薄冰,全部精力用来对抗外部还不够,对于团队内部制造麻烦消耗精力的人的态度 这次经历也让我对运维工作有了新的认识和更多的思考,在这里和大家分享一下: 操作层面 1. 线上操作无小事”,坚持 “双人复核”,坚持“按照流程操作” 端正心态,受过去经历和个人性格的影响,我是一个有一点个人英雄主义倾向的人,来到新的团队,更是急于证明自己,心态出了问题自然会导致路线跑偏,生产系统线上运维是一个严谨度要求非常高的工作
将应用或系统部署至不同环境;4.监控,对基础设施、应用或系统进行监控;5.告警响应,对告警通知的响应及处理;6.性能优化,对系统及相关组件性能进行优化;7.系统高可用,对应用系统中的单点进行高可用升级;8. 3 运维管理从运维现状来看,我们优先需要解决的是自动化的问题,而自动化的前提是标准化/规范化,而好的自动化需要配合可视化或web化,可以将我们80%或更多的工作进行优化。 因此目前我们总结的运维管理主要目标是标准化/规范化,自动化,可视化/web化。其中标准化可根据运维实际情况进行制定;而可视化/web化,可以通过开源工具或web开发实现。 7.2 运维管理文章开头说运维管理主要目标是标准化/规范化,自动化,可视化/web化,从切身体验来看运维管理的目标也是随着运维自动化阶段的不同而变化的。 运维自动化不是万能的,我们需要看清楚它的位置。(2)运维的本质到底是服务,是服务于业务,因为运维是用技术解决业务问题,运维的价值要依托于业务才能体现。
前言 笔者在上一篇文章《从Gartner IT成熟度模型谈Linux运维》中已经提到了红帽卫星。在这篇文章中,笔者主要介绍了如何通过红帽卫星提升客户OS 运维成熟度模型。 红帽卫星的核心,是围绕着生产运维标准化和自动化展开的。标准化的好处,笔者在上一篇文章已经做过介绍,本文不再赘述。至于红帽卫星如何通过自身功能,实现标准化和自动化,是本系列文章介绍的重点。 ? 两个数据中心要实现一体化标准运维。那么,就可以通过一套红帽卫星实现。将Satellite Server放置在一个数据中心,如北京,它管理北京数据中心并负责订阅产品的下载。 通过Satellite Server和Capsule server,既实现了多数据中心运维的统一性,又实现了管理模块的分布式。 ? 结合内容视图和生命周期管理,可以使客户的开发、运维、生产环境更加规范化和流程化。 总结:至此,笔者从架构角度介绍了Satellite的基本功能和内部一些架构。相信读者对此有了一定的了解。
在数字化转型浪潮中,企业终端设备数量呈指数级增长,混合办公、远程接入、信创终端混用等场景让传统IT运维模式面临前所未有的挑战。 据行业安全调研数据显示,超过72%的企业数据泄密事件始发于终端侧的不合规操作,而运维人员平均需要管理数百台终端设备,人工巡检、逐台排查故障的方式已难以为继。 3.2 远程协助与运维可视化远程协助模块突破了传统远程工具的局限,支持本地免开端口、客户端无感远程查看等多种模式。 管理员可在1秒内接管终端屏幕,同时提供交互模式(需客户端授权)、旁观模式(仅观察不干预)、兼容模式(双方均可操作)和独占模式(锁定客户端键鼠)四种控制策略,适配不同运维场景。 面对日益复杂的网络安全威胁与合规监管要求,将终端桌面管理纳入企业IT治理的战略规划,以技术手段实现标准化、自动化、可视化的运维体系,是保障业务稳健运行、筑牢数据安全防线的必由之路。小编:33