DevOps会是昙花一现吗

发布网友发布时间：2022-04-25 05:56

共2个回答

热心网友时间：2023-11-01 01:15

最近一两个月，一直有场景化运维、场景化大数据分析的声音围绕在耳畔，以Gdevops全球敏捷运维峰会杭州站上新炬网络执行副总裁程永新的“ 一切没有场景驱动的运维平台建设都是假大空！ ”最为振聋发聩。我们一直在谈技术，谈原理，谈内核，总以为“懂了”这些的人，就势必能广阔天地大有所为。技术固然重要，但偏离了业务/应用场景的技术，无法呈现业务价值的技术就非常不重要。技术也应该是场景驱动的，对于运维技术人员来说，离开场景学习的所谓高深技术，只是浪费时间。所以新同事进入一个新团队后，能使技术更好发挥作用的环境、流程的考核会占据了另外的三分之二。今天来谈谈Oracle坏块问题。坏块问题，相信做过两三年Oracle维护、支持的DBA都会遇到过，即使从来没遇到过的，看过Oracle 官方文档的甚至是会度娘或者谷哥的，应该也知道基本的处理手段。这是我内部分享的一个简单思维导图，如果有遗漏，欢迎在后面评论补充。面试的时候通常是这么问的：你了解Oracle坏块么？坏块为什么会产生？描述一下你处理过的坏块案例细节？如果你负责的好几个数据库都突然发生了坏块，你会怎么做？通常，前面几个问题的回答都不会太差。但是最后一个问题的回答，鲜有能出众的。原因在于面太窄，思维太窄。如果这个时候你还要一个个库的去看alert日志，那么显然就走错了方向。现实情况就是，我们的数据库可能是五六十套，或者上百套，你一套套库的去看这些日志里的报错的块，再根据块找到对象，确定是表还是索引，再去用坏块的修复手段去修复……那么，所有人都会被你害了。我们经历过，花了两天的时间，都没修复完一个库中几万个坏块的情况，在其他大牛还在哼哧哼哧做恢复的时候，我向领导提议启用了新的方案，在大老板没有完全失去耐性的情况下恢复了业务。真正正确的做法是，如果确定坏块数量为数众多，赶紧停业务，切灾备，后面再补数据。灾备是干什么吃的，养库千日，用库一时，就在这个时候了！

热心网友时间：2023-11-01 01:15

疫情和全球经济模式转变的影响加速了数字化转型，DevOps比以往变得更加重要了，并且DevOps也在不断发展以适应不断变化的需求。随着网络攻击的风险急速增长，安全性更显得至关重要。企业将越来越多地采用DevSecOps流程将安全性引入 DevOps。采用JFrog Artifactory+Xray的模式来快速响应不断变化的需求：提高安全敏捷性，优化性能和资源，早期检测和缓解漏洞，促进团队之间更好地运作和沟通。