看过猪跑的都知道，有专职的运维工程师这个岗位。...呆过大团队的，你也知道有专职的DBA，甚至Oracle DBA,MySQL DBA等等，这就是社会的进步带来更细的分工导致的，更细分的领域，更精致的专业，更专注的岗位。...讲的更深入一些，如果你的思想意识达不到某个层次，而让你做出某个境界的或思考某个领域的问题，你能想的到吗？...回忆一下，你上学哪会，有当下的这种解决问题的能力，看问题的角度，思想意识境界是慢慢培养出来的，不是那有，我看一下就掌握的。同样，程序员也不是说有个新框架放在哪，学一下就会的。这句话，得辩证看。...会用是一回事，用的好是另一回事。 其实就是广度与深度的问题，百科里有针对“T型人才”完美的解释，看程序员自身发展，其实看贯穿整个软件工程的分工。
但变的是办公方式，不变的是美创运维的7*24小时不间断支持。 这不，一位客户发来了一条消息： 客户:张工，好像我这个数据库服务器的内存使用率有点高啊，你帮我看看？...共享内存和tmpfs，即free命令中的shared部分 在正常的业务数据库系统中，cached较高是一件比较普遍的事情，尽量不要去手动清缓存，毕竟它是为了提高效率而产生的，如果冒然释放缓存会造成IO...美创科技拥有强大的运维中心数据库服务团队，其中Oracle ACE 1人、OCM 10余人、数十名Oracle OCP、MySQL OCP、红帽RHCA、中间件weblogic、tuxedo认证、达梦工程师...，并著有《Oracle DBA实战攻略》，《Oracle数据库性能优化方法和最佳实践》，《Oracle内核技术揭秘》等多本数据运维优化书籍。...今天的运维小技巧就分享到这了，下期再和美创运维团队一起学习运维知识吧！
运维工程师是IT行业中不可或缺的一环，他们负责维护系统的稳定性和可靠性，确保业务的正常运行。然而，随着技术的不断发展，运维工程师也面临着一些挑战和困惑，他们的出路到底在哪里呢？...35岁被称为运维半衰期，究竟为何？ 近年来，有一种说法称35岁是运维工程师的半衰期，意思是说在这个年龄之后，运维工程师的职业生涯会开始走下坡路。...运维工程师需要掌握的知识和技能非常广泛，包括操作系统、网络、数据库、安全等方面，因此需要不断学习和更新自己的知识和技能，以适应技术的发展和业务的需求。 深入了解业务需求。...运维的职业发展路径 运维工程师的职业发展路径有很多种，以下是其中几种比较常见的方向： 技术专家。运维工程师可以深入研究某一个领域或技术，成为该领域的专家，提供专业的技术支持和解决方案。 架构师。...虽然35岁被称为运维半衰期，但是运维工程师的职业生涯并不会因为年龄而走下坡路，关键在于他们是否能够不断学习和更新自己的知识和技能，以适应技术的发展和业务的需求。
数据库不仅仅是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供运维或研发人员使用，封装更高层的自动化运维系统。详细的工作职责如下所述。...任职资格: 1、2018届毕业生，专科及以上学历、计算机相关专业； 2、诚实守信，性格开朗，无不良历史记录； 3、善于学习，善于沟通，文档功底好，勇于面对挑战，敢于承担工作压力； 4、学生干部或有相关网络工程师认证...要做DBA，就要专门研究数据库，搞清楚数据库的原理结构，每个详细点。 每一门往后都有大量的东西要学习的，专精才能钱多，并且有成长。 不过当前都在往运维开发方向靠拢，未来的运维都要会一些开发才行。
资源申请和集群管理方式 为了更好的管理和维护，图数据库在运维部门集中运维管理。用户按需在工单平台中提交申请即可，工单中填写详细的资源需求数据和性能需求指标，由运维同学统一审核交付集群资源。...NebulaGraph 规范和架构设计 由于需要满足大量业务需求，未来会有大量的集群需要交付和维护。为了高效管理和运维规模化的集群，需要提前规划和制定规范。...端口 路径打包生成 rpm，作为标准安装包 图片 服务请求直接通过 DNS 和网关服务到 Graph，方便计算和存储服务直接交互，由于是通过 DNS 访问，不对外暴露 Meta 节点信息，可以更灵活的运维...，较少服务绑定 Meta 节点 ip 带来的运维代价。...图片 部署完毕之后，需要按照服务角色依次启动 start.yml 的脚本文件提前定义好三种服务的启动命令和配置文件。
，相比 JanusGraph 这类构建在第三方存储系统上的图数据库，性能和资源使用效率上具有优势； 支持两种语言，尤其是兼容主流的图技术语言 openCypher，有助于用户从其他使用 Cypher 语言的图数据库...考虑到使用图数据库的业务大多数据来自离线系统，通过离线作业将数据导入到图数据库中，数据一致的要求并不高，在这种条件下使用蓝绿部署能够在灾备和性能上得到很好的满足。...生产上的一个例子： 图片 上图为三机房情况，下图为蓝绿部署情况： 图片 中间件及运维管理 我们基于 K8s CRD 和 Operator 来进行 NebulaGraph 的部署，同时通过服务集成到现有的部署配置页面和运维管理页面...优化稠密点之关闭数据压缩，关闭 block cache 在没有特别好的方式避免锁竞争的情况，我们重新回顾了锁竞争的整个发生过程，锁产生本身就是由 cache 自身的结构带来的，尤其是在读操作的时候，我们并不希望存在什么锁的行为...NebulaGraph 二次开发 当前我们对 NebulaGraph 的修改主要集中的几个运维相关的环节上，比如新增了命令来指定迁移 storaged 中的分片，以及将 leader 迁移到指定的实例上
除了可以查看两个服务器之间的路径之外，MTR 在它的七列数据中提供了很多有价值的数据统计报告。Loss% 列展示了数据包在每一跳的丢失率。Snt 列记录的多少个数据包被送出。...当10个数据包全部发出后，得到的平均延迟可能是正常的，但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高，使用最好和最坏的延迟来确定平均延迟是一个较好的方案。...所以，当问题发生后，我们通常需要收集反方向的 MTR 报告。 此外，互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率，当出现短暂的10%丢包率时候，不必担心，应用层的程序会弥补这点损失。...当您经历网络问题后，可以选择提醒您的 ISP 提供商。当联系您的提供商时，需要发送一下 MTR 报告和相关的数据。没有有用的数据，提供商是没有办法去解决问题的。...然而大多数情况下，路由问题是比较少见的。比较常见的是因为物理距离太长，或者上网高峰，导致网络变的很慢。尤其是跨越大西洋和太平洋的时候，网络有时候会变的很慢。这种情况下，建议就近接入客户的节点。
前一段时间用户的系统进行应用发布和系统运维，准备了很久，结果我们最为担心的数据库维护环节没有出现问题，却在应用发布的阶段出现麻烦，因为程序未设置正确的字符集，导致插入了乱码数据，结果又不得不重来。...在很多重要的维护操作中，往往核心环节没问题，结果在微不足道的小地方折戟沉沙。...移动的朋友总结了一句话，非常有道理：运维保障总是从最高风险点开始逐步推进，悖论是如果这样推进的执行力有保障，出的问题总是之前觉得低风险的地方。...这也给我们一个警示：数据库运维或系统运维，每一个环节都要细致入微，唯有如此才能保障长治久安。...、数据库运维，监控是根本，及时发现、分析和解决出现的问题，是运维保障系统稳定的关键，任何一个简单的错误都不容轻忽。 加强监控，收集和分析足够多的数据，是系统的最佳保障！ 图：对客户系统错误的分析。
提出论点 好的研究想法，兼顾摘果子和啃骨头。...两年前，曾看过刘知远老师的一篇文章《好的研究想法从哪里来》，直到现在印象依然很深刻，文中分析了摘低垂果实容易，但也容易撞车，啃骨头难，但也可能是个不错的选择。...人的三维+时间半维 具体如何找到好的想法，一时半会没有头绪。因此，回到最初的起点，从人的层面，我有什么？我想要有什么？...再结合上面说的人自身三维+时间半维具体情况的充分条件，个人就很可能有好的工作想法。 写在最后 从个体的发展到组织的发展，组织也需要好的工作想法。...引用 好的研究想法从哪里来 杜跃进：数据安全治理的基本思路 来都来了。
2、数据库部署 该运维工程师出场了，项目初期访问量不会很大，所以单台部署足以应对在1500左右的QPS（每秒查询率）。...如果做双主，就会遇到数据库数据不一致现象，产生这个原因是在应用程序不同的用户会有可能操作两台数据库，同时的更新操作造成两台数据库数据库数据发生冲突或者不一致。...分布式缓存可以缓存海量数据，扩展性好，主流的分布式缓存系统有memcached、redis，memcached性能稳定，数据缓存在内存中，速度很快，QPS可达8w左右。...5、数据库维护 数据库维护是运维工程师或者DBA主要工作，包括性能监控、性能分析、性能调优、数据库备份和恢复等。...这些都是与运维相关的前沿技术，也是在存储方面主要学习对象，小伙伴们共同加油吧！哪位博友有更好的优化方案，欢迎交流哦。
下面一些同学，提出数据库不就是运维吗，不是很悲催吗，虽然这样说的同学不多，但给我一个很想表达不同观点的冲动。 搞数据库的到底是不是搞运维的 ？...我的回答是NO，NO, NO 那么为什么搞数据库的我不认为是搞运维的，首先我要重申一点，我个人一点都不认为，搞运维的是低端的，是不值钱的，想法我认为搞运维的同学，实际上技术水准应该更高，甚至要高于普通的开发者...至于运维同学怎么想，我想会有运维的同学来，去写这样的文字，来反驳。作为 DB 人员，我1000000万个不同意，搞数据库的就是搞运维的这样的观点。...BUG 的信息是从哪里来的，有一部分就是 DB 人员提出，甚至给出解决方案的。...说完这些你还觉得，DBA 是一个运维人员，这不是搞笑吗 ？
在企业IT工程师团队中，对“三分技术，七分管理”这句箴言的信奉者占据了绝大数。当多个行业企业信息化建设走过大规模新建期后，IT运维成为企业IT的常态。...系统、数据与业务的日益复杂，都加剧了企业IT运维的难度。...对大多数自建团队与多个供应商合作并存局面的企业而言，IT运维管理需要考虑内外部兼顾的情况无疑会令CIO们颇为头疼，比如医院、制造、金融、政府等政企行业用户。...某三甲医院IT管理者甚至表示，希望帮助寻求IT运维方面好的方案，原因在于他们日常工作主要是运维支撑，而医院大大小小系统几百个，对系统的精细化和个性化需求，导致IT服务商过多，如此复杂的情况让日常运维容易陷入被动且难管理...因此，企业要明白IT运维的目的是什么？如何能让IT运维提高企业的业务运营质量。
接下来我们会从上到下跟大家分享以下五部分：运维面临的挑战，敏捷开发方法，还有我们的运维看板，以及敏捷软件生命周期，最后是我们的结论：运维也可以敏捷。...运维的挑战 运维到底能在DevOps里面做什么？...，在这种小规模的小批量生产上，他会很快的试错，以及当车销量不好可以及时的停止生产方面的浪费，那么如果销量好，就会持续扩大生产以达到一定规模生产。...用看板转变是很好的办法，改变一点点，慢慢的开始，而不是一开始就上来一堆名词，PO,Scrum master，这些。 看板是一个非常好的启动变革的方式。...总结 运维与DevOps的整个过程这块等于把整个我们部署完以后运维怎么介入，以及运维在三个阶段里运维应该起到什么样的后续角色都描述进去了，其实就是SRE，还有解决部署的事情。
本文中的问题精选自上期【你问我答】——数据库专题中读者的提问。...如果你英语好，这些网上的教程也不错： https://www.sqlteaching.com/ http://www.w3schools.com/sql/default.asp Q2：我想问一下，这么些数据库...Redis、MongoDB属于非关系型的NoSQL数据库，KV存储。...Q4：能不能简单介绍下时序数据库的应用场景，和其它NoSQL数据库有啥区别？...Q6：数据库以及SQL优化的方案有哪些？ A：分几个层面: 1. 系统层面：纵向扩展数据库服务器配置，简单粗暴。 2. 数据库服务端层面：配置参数调优等，比如调整数据库连接缓冲区大小。 3.
而运维作为IT运行的有力保障，在不同时期和不同类型的企业中正在发挥着越来越大的支撑和引领作用，今天就让我们聊聊信息化时代的传统运维、互联网时代的互联网运维和数字化时代的业务运维有什么不同！...传统运维部门在制订IT设备和信息化系统管理目标时，关注的是一台台IT设备的故障率和一套套应用系统的可用性，在基础设施、数据库、中间件、灾备、存储等环节通常大量采用商业闭源的软硬件产品及其解决方案，设备的开放性差...随着IT规模越来越大、系统越来越复杂，运维保障工作由最初的硬件运维不断细分，网络工程师、系统运维工程师、DBA、安全工程师等岗位加入到运维体系中，系统管理采用各种重耦合的ITSM、ITOA软件，如IBMTivoli...因此，互联网运维在基础设施、数据库、中间件、分布式存储、自动化部署等环节通常大量采用开源或基于SaaS的自动化运维监控工具，如Zabbix、Nagios和云智慧监控宝等，这些产品的横向扩展能力很强，具有分布式...未来，随着机器学习、深度学习等技术的不断成熟，AI技术将在业务运维体系中得到广泛的应用，共同推动IT运维市场的进步，而这就是业务运维在几年之后发展方向——智能运维AIOps。
运维管理的变革和向自动化运维的转型。...反过来讲，比如我们将企业内一个数据库VM交付的流程通过蓝鲸自动化运维平台，固化成一个流程，这个流程，运维人在自动化平台上可以一键交付；如果这个流程后续满足不了标准化的要求，我们只需要调整中间的流程节点即可...蓝鲸，轻松实现全方位的 数据中心基础架构自动化 数据中心是企业的IT心脏，涵盖了从中间件、数据库、操作系统等软件到堡垒机、防火墙、路由交换、备份存储、服务器等硬件的基础架构。...可以看到，基于OASR方法论构建的蓝鲸平台，在自动化运维基础架构层面，能力是非常强大的。 ? 操作系统生命周期自动化管理 ? 数据库DBA统一工作台 ? 中间件管理工具之一__配置及监控管理 ?...IT运维自动化时代已经来临，对于企业而言，这是更迭自己IT运维管理模式与阶段的时代，对于运维人而言，也是可以大展拳脚的时代。 而蓝鲸能够在企业IT运维转型及运维人的转型上，助一臂之力。
关于为啥没有洞察运维的本质主要原因可能是对运维不够热爱没有全身心的投入吧。 虽然今天依然没有洞察运维的本质，但是在这里还是乐意分享一点儿对运维的思考。...运维的境界 这里先从运维的岗位为切入点来谈起，当我们浏览招聘网站搜索运维岗位，从偏技术的角色来看大多是这些：运维工程师、中级运维工程师、高级运维工程师、资深运维工程师、运维专家；从偏管理角色来看大多是这些...下面是我思考得出的运维的三个境界： 为他人 运维日常处理需求、输出参考意见、乃至救火等等表面上都是给他人提供服务的，然后年终考核也多要参考他人对运维的评价，然后很自然的运维也以服务人员自居，所以这一阶段基本上所有运维人员都能达到...这里强调运维此阶段当有了文化，产生了信仰，大家在制定的规则文化下自驱的去运转与维持，最终淡化了运维对公司的影响，必要时也有可能消灭了运维，但又有种运维无处不在的感觉。...最后还回到运维岗位上来？试问那家公司有运维科学家或者运维艺术家这个岗位？如果有那么这家公司当知运维的真谛，从而也给运维的天花板定的足够高，运维在这里当大有作为。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
