运维:打败你的不是天真,是无邪!
对于运维,我觉得有一句流行语非常适合“打败你的不是天真,是无邪”,只有“天真”的入行,“无邪”的坚持,才能让你承受住运维行业的“厚重”!
运维:你的盲区在这里!
“在实际调研过程中,往往存在专家太忙,太多重要的事情要做等现实困境” “我们目前在做内核行为可观测性的产品,希望能够解决运维排障时的一些痛点!” “团队原来做的是Kindling开源,但是发现内核这东西对很多人太复杂,特别是对运维或者业务开发,很难直接拿来为自己工作提供便利,所以就出来单独做了个完整产品。” “挺担心变成闭门造车的,所以目前也找了很多公司做技术交流分享!”
云原生场景下,容器化和微服务如何组CP?
容器化进程中,CMDB式的CP可以在不改变当前架构的情况下兼容容器场景,这个错位CP虽然给我们的架构带来了时间和空间上的过渡,但是架构不易,要想改变现状还需要架构及解决方案等大佬们去统筹全局,而非一朝一夕能够完成!
扯淡的DevOps,我们开发根本不想做运维!
在软件开发领域,DevOps的理念已经越来越普及,但在实际应用中,却存在着不少争议和误解。本文将从开发者视角出发,质疑DevOps在实际开发过程中的可行性,分享开发人员对于运维工作的真实想法。让我们一起来看看,究竟是什么原因让开发者对DevOps产生抵触情绪,以及如何化解这一矛盾。阅读本文,你将获得对DevOps更深入的理解,以及找到提高开发与运维协作效率的启示。
云原生网关调研,运维把把脉!
随着架构向元原生架构演进,运维的视野也在从流量网关(Nginx)、服务网关(API Gateway)向Ingress Controller、Gateway Controller逐步转变,这不只简单是运维工具的切换,而面向的是整个云原生知识体系。首先这不是要革咱们运维的命,而是让我们通过回顾过去来更好的体验技术之美。
临时工说: 他们说DBA 是IT 行业的职位的常青树,你信吗
最近和一个开发的友人聊天,他发出感慨,你们DBA 是一个好职业,知识不怎么变化,还越老越值钱, 并对开发人员行业的内卷和苦楚进行了一段论述。
LDAP:打开潘多拉宝盒的钥匙
在企业的平台建设中,运维需要面向各种运维管理系统: 监控类系统 大数据类系统 安全类系统 CI/CD类系统 企业办公类系统 等等
关于DBA这个角色职业未来之我见
讨论一个技术角色的未来,实际就是从事这个岗位的人有没有未来。
微服务井喷时代,我们如何规模化运维?
随着云原生技术发展及相关技术被越来越多运用到公司生产实践当中,有两种不可逆转的趋势:
运维浅聊容灾演练
那么面对多数据中心,我们当前的应用架构应该如何演进呢?这个答案不是我这个运维能够解答的,但是这不妨我们去参考一些过来人的案例,例如「携程的Apollo」 。
DevOps级 和 CMDB级流水线其实是不一样的!
近期听了几场关于DevOps的交流,作为运维当然是对流水线这块比较关注了。虽然大家都比较关注的是项目协同和研发流程、开箱即用及可扩展的流水线等的结合,但我思考的是这是否已经足够满足我们目前的需求了呢?为什么这么说呢?因为我们有CMDB,而且CMDB级 和 DevOps级的流水线管理其实是不一样的。
MySQL:Got an error reading communication packets
相信只是运维MySQL的DBA一定不会对这个note陌生,这里简单将形成的可能性进行分析,仅供参考。
运维请收藏!一篇文章告诉你日志分析、告警管理、服务网关的重要性…
随着网站规模越来越大,单体应用往往很难再满足要求,就需要向分布式,微服务架构演变。 那么这个演变过程是怎么样的呢?都涉及到哪些组件,会遇到哪些问题,以及相应的解决方案都是什么,本篇文章就来回答这些问题。
企业数据库安全管理规范 | 运维进阶
本文梳理了数据库安全管理的各项要求和注意事项,详细实用。供大家参考。
Ansible 持续集成Anolis、Ubuntu基线配置
因此我们结合《CentOS停服替代后,哪些操作差异你知道吗?》一文对Anolis8.6 和 Ubuntu22.04 操作系统的差异化操作,通过Ansible Playbook再次纳管了Anolis8.6 和 Ubuntu22.04两个操作系统的初始化配置和安全基线,实现自动化配置的可持续性。
敏捷研发—前端DevOps流水线实践
本文介绍了如何将DevOps理念应用于前端开发的实践指南。从前端开发的背景现状及问题分析入手,详细介绍了前端DevOps中的流水线设计、需求管理、代码构建、测试部署、性能检测等方面的实践方法和工具,并结合案例分析和实践建议,帮助读者深入理解和掌握前端DevOps的核心概念和实践技能。
OB运维 | tenant--删除租户的流程设计
ob中的租户相当于我们平常认知的数据库集群,对外提供数据库服务。 当需要删除ob中的租户时,会删除该租户下的所有对象,包含数据库、表等。 数据是⾮常重要的,为了避免意外情况, 此时,你可能需要设置多种策略,以便确认&处理⼀些异常场景。
侃透了:运维人的自我修养
“ 他强任他强,清风拂山岗”,在技术趋势不断变迁的今天,我们唯有保持“自驱力”的清风,才能越过重重的山岗,这就是运维人的自我修养!
OB运维 | tenant--删除租户的命令
删除租户后,租户下的数据库和表也同时被删除。 但是租户使⽤的资源配置不会被删除,资源配置可以继续给其他租户使⽤。
读“运维岗位真的不能干了吗”有感
现在这个阶段,平台体系还没有那么完备,使用自助Platform+COE+BP(Business Partner)的架构来搭建运维体系看起来是靠谱可落地的。未来Platform足够好的的时候,可以缩减BP人力(BP也慢慢具备了COE的能力),Platform继续完备,可以继续缩减COE,再之后,嗯,运维和研发可能就都不需要了吧。