企业运维团队担负着对IT基础设施运维的重要使命，核心任务是保障生产安全运营。IT基础设施规模的不断扩大，业务不断复杂，使得日常运维工作面临更大的压力与风险。...在运维管理工作中的主要痛点可以归纳总结为以下几个主要问题： (1)、运维系统界面多，风险不可控：日常巡检、服务请求、问题查询都通过登录不同的运维平台进行操作，背后对接的都是生产系统，误操作风险大。...(3)、运维缺乏统一标准，工作规范性差：新员工对现有的工作制度、工作流程需要一个逐步适应和熟悉的过程。...不同的运维系统有不同的操作流程，不同人员对应用系统的运维管理工作细致程度存在差异，缺少统一标准，导致运维复杂度搞。...建设自动化运维管理平台的主要目标就是：使得底层对接资源层，使用各类技术工具以实现自动化操作，横向对接配置管理平台、流程平台、监控平台和数据管理平台，贯穿整体统一运维管理框架，以实现自动化部署、批量变更、
这是学习笔记的第 2076 篇文章 今天整理了下运维方向的一些工作，想了想，其实可以做得扎实一些。 但是我们的工作每天会被各种琐事缠绕，有没有什么好的思路和建议呢。...我觉得你可以把你一整天的工作情况都罗列下来，毫无疑问，你需要是个有心人，你得关心自己的工作情况，把耗时和时间的分配情况都记录下来，便于追溯。...既然日常的事务性工作不可避免，我就以基础运维的工作为切入点，来逐步深入了解一些运维架构和优化的内容，这是一个初版的内容，有了这些信息之后，就可以重新审视现在的工作情况，基础运维方向哪些还需要补充和改进，...出发点大类细类是否具备自动化是否有批量需求引申方向基础运维安装部署单机多实例**** 容量评估 一主多从部署**Y容量评估 分布式集群部署 Y分布式架构选型 高可用部署*** 高可用方案选型 新版本部署支持...新特性调研 资源池管理 Y 资源申请流程接口**Y 服务启停管理 服务配置管理 Y 权限管理新增数据库账号*** 数据库权限变更***Y 系统权限开通****Y
返回上一个进程的返回值 $$ 返回当前运行进程的PID $! ...(可以启动一个要运行几天甚至几周的进程) #renice 通过修改进程的优先值，调度进程的发生 #at，crontab 通过定时处理相关的程序调度 #kill 中断一个后台进程进行相应的调度...txpck/s：每秒钟发送的数据包 rxkb/s：每秒钟接收的字节数 txkb/s：每秒钟发送的字节数 rxcmp/s：每秒钟接收的压缩数据包 txcmp/s：每秒钟发送的压缩数据包 rxmcst/s...-u:输出CPU使用情况的统计信息 -v:输出inode、文件和其他内核表的统计信息 -d:输出每一块设备的活动信息 -r:输出内存和交换空间的统计信息 -b:显示I/O和传送速率的统计信息 -c:输出进程统计信息...| head -10 主要考察对sort、uniq命令的使用，相关解释如下，命令及参数的详细说明请自行通过man查看，简单介绍下以上指令各部分的功能： sort: 对单词进行排序 uniq -c
RPA应用于运维实践 RPA在运维的地位 在各行业企业中，近几年已经在逐步建设或已经建设了运维管理平台，而RPA技术作为运维管理的基础功能，在IT业务巡检领域里应用得越来越广，并且越来越显现出其RPA的优势...运维场景流程梳理 以下以某运维流程为例，要想通过RPA来实现，先从使用者用户的角度详细梳理整体操作步骤，形成流程图，这个步骤的过程需细化到最小的操作单元，例如点击选取某个下拉框、点击某个按钮、在某个对话框输入指定内容等...RPA在IT运维的优势 RPA应用于IT服务环节的优势： 标准化IT流程以减少人为错误； 自动化工作流，使新员工更轻松地实现同样的结果； 帮助集成来自不同供应商的不同产品以有效管理IT问题； 通过快速响应...总结 总体来看，RPA的技术的诞生突破了用户侧个性化操作而又难以模拟的技术壁垒，对于乐于对新技术的探索和采用的IT人员，尤其运维人员，更是一大福音，对于繁杂、重复、低效的低技术的运维操作，RPA一一解决...，运维人员也从中释放出大量的时间。
结合我们工作的思考：运维部门从成立之初就建立产品可用率制度，与产品一起设立可用率目标，可以说在量化运维质量目标与平衡产品迭代速度方面做得还可以。...2.运维工作工程化 谷歌SRE通过软件工程的方式去提高运维效率和解决问题，鄙视手工方式操作，一是传统运维方式对于快速发展的业务及达到百万服务器规模的数据中心，通过堆人的方式已经远远满足不了了，二是谷歌SRE...日常琐事过多，工作经常被中断，是运维工作效率无法提升的一个难题，谷歌SRE破解这个难题主要有2个方式，一是通过on-call轮值的值班制度，让一部分人能够有整段的时间去做工程；二是从整体上评估运维琐事工作量...，增派人力或将运维工作转移给开发部门来控制整个部门的琐事占比。...最后，开发与运维不是天然对立矛盾的，只是需要大家确立为产品发展的共同目标，在产品创新速度与稳定性之间寻求到平衡。我们在思考自身运维工作的时候，会始终坚持上面这个观点。
编写一个getarp.sh的脚本，记录局域网内各主机的MAC地址。 保存到/etc/ethers文件中，若此文件已存在，则先转移进行备份。 每行一条记录，第1列为ip地址，第2列为对应的MAC地址。...编写一个scanhost.sh的扫描脚本，检查有哪些主机开启了ftp服务，扫描对象是/etc/ethers中所有的ip地址。...#需要扫描的网段 FILE="/etc/ethers" [ -f $FILE ] && /bin/cp -f $FILE $FILE.old # -f为强制复制 HADD...> $FILE fi let HADD++ done #保存退出，进行扫描： [root@localhost ~]# . getarp.sh #扫描的时间长短...，与定义的扫描范围有关。
删除 DaemonSet 将会删除它创建的所有 Pod。...在每个节点上运行监控守护进程，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代理，或 Ganglia gmond 一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个...一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。...DaemonSet模板 查看DaemonSet必要字段 DaemonSet的描述文件和Deployment非常相似，只需要修改Kind，并去掉副本数量的配置即可。...DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
前面几篇主要讲了应该怎么做好运维，期间就会想到很多反模式，但是限于篇幅就没有多写。...这篇单独说说，运维过程中的一些反模式，也就是——为什么道理都懂（文章看到了不少，大会参加了不少，业界方案也都懂），却依然做（guo）不（bu）好（hao）运（yi）维（sheng）？...4、专家的思维模式，这一点在一些工作经验和背景比较资深的老鸟身上很明显，带着之前经历的光环来到一个新环境中，只要是跟自己经验范围内不太相符的东西，就这也看不惯，那也看不惯。...5、视野局限，做技术只考虑技术，做运维只关注运维，这个是最要命的，不能全面的考虑问题，以运维举例，如果我只考虑运维的事情，其实只要做做网络管理、硬件和操作系统管理就好了，因为这才是只跟运维相关，跟其它团队无关的事情...先写这么多吧，之前写过一篇《谈谈运维的价值》，也可以看看。
某些级别的RAID技术可以把速度提高到单个硬盘驱动器的400%。磁盘阵列把多个硬盘驱动器连接在一起协同工作，大大提高了速度，同时把硬盘系统的可靠性提高到接近无错的境界。...Mirror虽不能提高存储性能，但由于其具有的高数据安全性，使其尤其适用于存放重要数据，如服务器和数据库存储等领域. (3) RAID 0+1 正如其名字一样RAID 0+1是RAID 0和RAID 1...，从其它N个硬盘中的数据也可以恢复原始数据，这样，仅使用这N个硬盘也可以带伤继续工作（如采集和回放素材），当更换一个新硬盘后，系统可以重新恢复完整的校验容错信息。...使用的容错算法和分块大小决定RAID使用的应用场合，在通常情况下，RAID3比较适合大文件类型且安全性要求较高的应用，如视频编辑、硬盘播出机、大型数据库等. (5) RAID 5 RAID 5 是一种存储性能...归纳起来，RAID 7的主要特性如下： 所有的I/O传输都是异步的，因为它有自己独立的控制器和带有Cache的接口，与系统时钟并不同步所有的读与写的操作都将通过一个带有中心Cache的高速系统总线，我们称之为
那接下来我们对每个层级运维人员需要注意的细节： 1) LVS负载均衡层 LVS负载均衡层主要用来抵御大流量及转发数据功能，一般基于TCP/IP 四层协议进行转发，根据不同的内部环境使用的转发方式也不一样...运维人员在维护LVS中，需要密切关注LVS当前转发连接数及系统LVS日志。通过监控平台监控VIP、真实IP的情况、连接数的情况。...作为IT运维人员在日常运维中，需要长期的关注网站的整体运行情况，分析网站瓶颈，不断优化Nginx的相关参数，并确保Nginx跟后端服务连接是否有异常等。...在日常的运维中，需要注意后端服务层的监控，及连接数的问题，要实时关注并监控后端服务的正常，配置多实例，冗余案例。...对于IT运维人员在维护数据库时需要密切关注数据库并发数、连接池等变化，关注数据库主从、读写分离状态及日志的变化情况，并制定完整的备份机制完成数据库的备份，有问题及时处理。
图片3.数据库 系统的数据库监控从可用性、性能、占用资源、安全事件和异常错误等多个方面对数据库进行全面监控，如响应时间监测、连接进程数监测、连接客户端监测、指定进程监测、长事务监测、锁监测...、进程回滚监测、数据库空间监测和数据日志监测等。...支持ORACLE、Sybase、DB2 、SQL Server、Informix、MySQL等多种数据库。...图片4.中间件 中间件是位于网络、操作系统和数据库之上和应用系统之下的一种独立的系统软件或服务程序，常见的中间件类型有交易中间件、消息中间件、RPC中间件、应用服务器和WEB服务器等。...系统的中间件监控从可用性、性能、占用资源、安全事件和异常错误等几个方面对中间件进行全方位监测，如Apache监测内容包括服务进程监测、负载监测、请求监测、闲置监测、内存使用情况监测和数据库连接监测等信息
数据库不仅仅是dba的工作，每一个测试人员也应该懂得基本的数据运维操作，因为数据库是数据承载的地方并且是系统中非常重要的一部分，所以我们也需要熟练的对数据库进行基本维护。...4.2：导入某些数据表 mysql -uusername -ppassword testdb1 < tables.sql 或者 mysql>source tables.sql; 02、shell脚本实现数据库备份...是特殊的表示符 export PATH=/bin:/usr/bin:/usr/local/bin #进行环境变更的设置 TODAY=`date +"%d%b%Y"` #获取日期，进行变更赋值 DB_BACKUP_PATH..."Error found during backup" #输出失败的提示语 fi 03、使用mysqlbinlog恢复数据 ---- binlog配置： 在MySQL配置文件my.cnf文件中的mysqld...总结：数据库的运维对于测试人员来说仍然是非常重要的，比如：非常重要也不太容易构建的测试数据需要做备份操作时，数据库的运维就显得很有技术含量，掌握数据的基本运维可以使测试工作做得更出色，同时也会让开发刮目相看
这是学习笔记的第 1827篇文章 在数据库运维中对运维场景建立连接是一种很不错的方式，通过建立连接使得我们可以把原本单一的问题通过流程化的方式衔接起来。 以下是近期的一些实践和思路。...业务和运维团队之间工作的一个纽带就是工单，当然目前还没有明确的工单结算方式，但是可以很明确的说，工单是我们输出给业务方的业务价值体现。 ? 在业务价值体现的过程中，我们可以把技术价值也打包进去。...有了这一层的效果，后期我们要推出SQL自动化上线其实就是一件水到渠成的事情了，我们目前暂规定SQL打分超过80分的可申请自动化上线，自动化上线可以使用最少的审批环节，最快的数据处理速度，对于业务来说更加具有吸引力...当然业务巡检的情况和SQL审核类似，页面开发出来了，但是还没有完全推广用起来，我觉得这个地方的一大改进就是把监控和报警结合起来，监控数据能够推送出报警，报警信息可以间接调用巡检接口，这样对于运维同学来说...，就会收到相关的巡检报告了，这种类似快照的报告形式对于处理问题的时候就会省去很多的精力。
之前对数据库恢复做了相对全面的整合，为了校验数据恢复质量，我们开启了近半年的数据随机恢复测试，也就是说为了验证数据库的恢复质量和效率，我们会每天从备份机里面随机选取12个数据库实例进行数据恢复测试...在早期的指标设定中，我们很快达到了从70%改进到了90%，按照这个步调，想达到更高的目标看起来指日可待，比如我拍脑袋指定了一个指标99.9%，但是尴尬的是，以月份为单位，总是会在有那么1个实例恢复失败，...但是失败的场景又难以复现，所以一直没有实现这个目标。...有时候在想到底是为什么，今天突然琢磨了下，原来就是一道很简单的数学题。...所以拍脑袋的指标真是啪啪打脸，还是得做一个简单的计算来坐下评估，当然对于这个问题我觉得可以基于统计学的角度来做更进一步的分析，因为结合实际的业务场景，有很多改进的角度，我会在评估后给出一个可行的指标。
运维组织结构 简介 运维的工作方向比较多，随着业务规模的不断发展，越成熟的互联网公司，运维岗位会划分得越细。...应用运维 应用运维负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作，对服务进行例行排查、故障应急处理等工作。详细的工作职责如下所述。...数据库运维 数据库运维负责数据存储方案设计、数据库表设计、索引设计和SQL优化，对数据库进行变更、监控、备份、高可用设计等工作。详细的工作职责如下所述。...运维研发 运维研发负责通用的运维平台设计和研发工作，如：资产管理、监控系统、运维平台、数据权限管理系统等。提供各种API供运维或研发人员使用，封装更高层的自动化运维系统。详细的工作职责如下所述。...要做DBA，就要专门研究数据库，搞清楚数据库的原理结构，每个详细点。 每一门往后都有大量的东西要学习的，专精才能钱多，并且有成长。 不过当前都在往运维开发方向靠拢，未来的运维都要会一些开发才行。
随着图数据库的发展，相关系统应用越来越成熟，于是引入专业图数据库来满足这部分业务需求的事务也提上日程。接下来要考虑的问题就是图数据库选型了。...资源申请和集群管理方式 为了更好的管理和维护，图数据库在运维部门集中运维管理。用户按需在工单平台中提交申请即可，工单中填写详细的资源需求数据和性能需求指标，由运维同学统一审核交付集群资源。...NebulaGraph 规范和架构设计 由于需要满足大量业务需求，未来会有大量的集群需要交付和维护。为了高效管理和运维规模化的集群，需要提前规划和制定规范。...端口 路径打包生成 rpm，作为标准安装包 图片 服务请求直接通过 DNS 和网关服务到 Graph，方便计算和存储服务直接交互，由于是通过 DNS 访问，不对外暴露 Meta 节点信息，可以更灵活的运维...，较少服务绑定 Meta 节点 ip 带来的运维代价。
经过调研，我们选择分布式图数据库 NebulaGraph 作为管理的对象，主要基于以下几个因素考虑： NebulaGraph 开源版本即拥有横向扩展能力，为大规模部署提供了基本条件； 使用自研的原生存储层...，相比 JanusGraph 这类构建在第三方存储系统上的图数据库，性能和资源使用效率上具有优势； 支持两种语言，尤其是兼容主流的图技术语言 openCypher，有助于用户从其他使用 Cypher 语言的图数据库...考虑到使用图数据库的业务大多数据来自离线系统，通过离线作业将数据导入到图数据库中，数据一致的要求并不高，在这种条件下使用蓝绿部署能够在灾备和性能上得到很好的满足。...生产上的一个例子： 图片 上图为三机房情况，下图为蓝绿部署情况： 图片 中间件及运维管理 我们基于 K8s CRD 和 Operator 来进行 NebulaGraph 的部署，同时通过服务集成到现有的部署配置页面和运维管理页面...NebulaGraph 二次开发 当前我们对 NebulaGraph 的修改主要集中的几个运维相关的环节上，比如新增了命令来指定迁移 storaged 中的分片，以及将 leader 迁移到指定的实例上
当-B后的数据库列全时 同 -A参数。请看-A的说明。...加上读锁 mysqldump -A -F -B --lock-all-tables |gzip >/data/backup/$(date +%F).tar.gz 特别提示：有关MyISAM和InnoDB引擎的差别和在工作中如何选择...-----+ | thread_cache_size | 8 | +-------------------+-------+ 1 row in set (0.00 sec) 查询缓存 它涉及的主要有两个参数...计算带宽大小主要的有2个主要指标（峰值流量和页面大小），我们先做出必要的假设： 1. 峰值流量是平均流量的3倍； 2. 每次访问平均的页面大小是100KB左中。...当然，这个结论是根据前面提到的两点假设得出来的，具体值则需要根据公司实际情况来计算。 数据库服务器是重中之重，因为网站的瓶颈问题大多出在数据库身上。现在一般的中小网站多使用MYSQL数据库。
前一段时间用户的系统进行应用发布和系统运维，准备了很久，结果我们最为担心的数据库维护环节没有出现问题，却在应用发布的阶段出现麻烦，因为程序未设置正确的字符集，导致插入了乱码数据，结果又不得不重来。...在很多重要的维护操作中，往往核心环节没问题，结果在微不足道的小地方折戟沉沙。...移动的朋友总结了一句话，非常有道理：运维保障总是从最高风险点开始逐步推进，悖论是如果这样推进的执行力有保障，出的问题总是之前觉得低风险的地方。...这也给我们一个警示：数据库运维或系统运维，每一个环节都要细致入微，唯有如此才能保障长治久安。...、数据库运维，监控是根本，及时发现、分析和解决出现的问题，是运维保障系统稳定的关键，任何一个简单的错误都不容轻忽。 加强监控，收集和分析足够多的数据，是系统的最佳保障！ 图：对客户系统错误的分析。
运维和可运维性比以往任何时候都重要。让我们从较高的角度看待运维行业的发展、新兴挑战以及这一切都会对我们的职业产生影响。...二、运维已死，运维万岁 (原模式下的)运维团队正走在渡渡鸟之路(译者注: 渡渡鸟是一种著名的已灭绝动物)，但是可运维性、弹性伸缩和可靠性却从未如此重要。...这里有大量喜欢构建基础设施即服务解决方案的软件工程师，还有专门的运维人员角色来大规模地运维这些基础设施，以及大规模地管理数据服务。...4、技术投入的管理(Managing the portfolio of technical investments) 可运维性是最长期的技术投入，也是技术债最主要的来源，而运维工程师又是最能帮助评估和解决这些风险的人...运维现在是每个人的工作，而许多工程师不知道这意味着什么，但已经吸收了挥之不去的恐怖文化。 我们需要纠正错误的观念。 我们必须找到奖励尝试而不是惩罚探索的方法。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
