关于运维:中台和多云管理是伪问题运维要集体下岗了吗

32次阅读

共计 2759 个字符,预计需要花费 7 分钟才能阅读完成。

运维还有将来吗?来看看群友怎么说?

01

如何对待中台和多云治理?

@A1:我认为这两个都是伪问题,没有钻研价值,相似 IT 行业的气功治疗法。多云治理是资源纳管平台,实现基础设施资源对立治理和调度。云计算解决的是分布式网格计算问题,也就是算力问题。也就等同于利用 CPU、内存、存储、网络等基础设施资源实现分布式计算、网格计算能力,通过提供标准化的基础设施资源计算服务(IaaS 服务),撑持不同企业的大数据量计算和存储等需要。

@B2:能够去用代码治理各种云的资源设施~ 移植、复制、降级,都会容易些~ 下面两个可能还不够用,还须要多个环节去帮忙完满实现,讲真一个企业用多个云,很多场景是必须的,有价值的~

@A1:这种云计算的认知,还是把云当做特大号 idc,只是存储计算网络三大件的资源池。实际上,云计算远远不只是一个资源池。云计算的定义能够有多个角度,咱们先谈开发者角度:云计算是通过 API 把 Infra 和底层模块形象为服务,用以晋升开发经营效率的平台。

@C3:“云计算”这个概念或者符号原本就是用来简化简单的事实场景的,就像人要取名字一样啊,这些分享和文章只有是正当的去解释某一个局部的场景,就是有肯定价值的,可能你不喜爱,那你应该分享你的“观点”。

02

运维是不是要个体下岗了

@A1:我的文章,共大家打靶子

https://mp.weixin.qq.com/s/Vk…

@D4:看这题目就不必看了,还定位运维在传统岗位上。当初网工都在开发自动化产品,早不是过来那个时代了。

@C3:这篇的新意在哪里?我要的是新“观点”

@A1:没啥新意,就是把我公司的做法总结一下,咱们曾经干掉了运维,连带 dba 和专职测试都被干了,只有网工和平安还在,其余都是 dev。

@E5:求教一下,没有运维的话,公布平台谁来负责啊?洽购的第三方公布工具吗?还是让每个研发都去学 ops,做 CI/CD?

@F6:第一次据说不须要运维的,是不是要把运维的工资给开发,让开发去运维呀

@A1:对,devops

@G7:那么,devops 岗位算开发还是运维嘞

A1:基本就不应该有这个岗位,有这个岗位的公司,都是被伪专家忽悠了

@H8:https://www.zhipin.com/job_de… 看一下被忽悠的公司?

@A6:什么都让开发干就行了,运维 测试 前端 挪动端,让后端一个人做就行了,后端无所不能。

@I9:这个思路不是干掉了运维,而是间接买了他人的运维相干的服务吧。

@J10:devops 不是开发和运维的桥梁吗,怎么成把运维干下岗了..

@A1:是的。all in cloud

@A5:阐明还是小公司,买服务就够了,不须要业余的效力团队来解决简单问题。

@I9:我不太确定您公司的服务量级哈,这个两个抉择就从简略的老本下面感觉就是不对等的。

@J10:就算有自动化服务,也须要人去干涉吧

@A1:一千个微服务,研发团队四千人,不算大,也不算小

@A6:公司到了肯定规模 不都是自研嘛?只有小公司才是考现成的 sdk

@I9:这四千人外面没有人来做本人的 devops 相干的平台建设吗?还是间接走云的那一套流程的?如果间接用的话,在落地适配的时候没有什么不适应的中央吗?咱们这毕竟是平安沙龙哈,那 devops 这些须要和平安挂钩,卡点的局部应该怎么做呢?

@A1:有个 internal developer platform 团队,规模还不小,然而他们只是把云和其余 saas 厂家的工具粘合起来。他们不是运维,不对 sla 负责。我也在摸索。

@K11:我看大家对干掉 ops 争议挺大的,其实您有机会能够来前线分享一下最佳实际,把具体怎么做摆出来也会比拟有说服力,可能是个很有价值的探讨。

@A1:其实没什么争议。除了运维总监们,大家都感觉运维团队要被干掉

@H8:这个不错 如何干掉运维那也是最高效的形式?教教咱们

@K11:这个群里运维不多,很多还是开发的,实践上并不对运维被干掉有多大的冲突,只是没有看到你们的最佳实际所以有异议。

@L12:所谓的 all in cloud,无非就是把运维的活丢给云平台去做了。并不是不须要运维。理论业务场景,私有云只是一种模式,规模更大的公司肯定是混合云,所谓的干掉运维这是噱头。根底平台须要研发和运维。

@M13:运维有很多日常工作,很繁琐的,比方凋谢平安组,加白名单等等这些小活儿

@A1:所以平安团队当初就搞个爬虫,在公司每个 repo 里巡逻,看到老版本的镜像,就提交个降级版本的 pr 看得出来,你没正经用过云,顶多在云上开了一百台虚拟机。

@L12:devops 工具和云计算解决了很多重复性的工作,进步了效率。大公司自身曾经有很多 AIOps 的实际了。大一点规模的公司,业务的日常扩容,容量布局都曾经自动化了。说干掉运维是童稚。

@N14:一个律师因为会蛋炒饭,而后把厨师炒了,而后在他人做律师工作的时候去掌个勺

@B2:明天我还在写文章,feature flags 是如何让 DevOps 更并重 Dev 的?我也特地关怀这个话题 devsecops~ 我之前搞过 devops,mlops,唯独对 devsecops 没教训,尤其是想关注咱们的产品是否在 devsecops 里会有一些利用场景

@A1:当初什么都 shift left,然而平安真的移不动,没人违心做平安工作。咱们的平安工作,都是依附平安团队邮件驱动。比方最简略的容器镜像打补丁,真的很烦。所以平安团队当初就搞个爬虫,在公司每个 repo 里巡逻,看到老版本的镜像,就提交个降级版本的 pr。

03

dev 和 ops 同学怎么对待平安?

@O15:

https://github.com/cncf/tag-s… 搭车举荐,参加翻译了云原生平安白皮书中文版

@A1:好多中央要求太高了,“为了让客户端和服务器通过加密技术双向验证身份,所有的工作负载的通信都必须进行互相 / 双向认证。”,mtls 带来的益处抵不上施行老本。

@A1:内容品质很高,然而显著是平安从业者写给平安从业者的,没有思考到其余团队对可施行性和老本的需要。

@C3:零碎被浸透之后,mtls 就有价值了。tag-security 原本就是平安的分支,平安畛域须要专业人士,这个文章很值得实际。

@H8:咱们最近也接入 authing 了,刚提到 authing 怎么解决 ram 平安问题的?

@B2:咱们也用上 authing 了,平安、省心

04

当初都是 IaC 化

大家有关注 IaC 的安全性吗?

@Q4:当初一切都是 IaC 化,大家有关注 IaC 的安全性的吗?

@H8:国外像 Synk checkmark 等很多产品都开始反对 IaC 平安这块,因为当初资源、网络甚至一些 SaaS 服务都能够被编排,IaC 呈现问题那可能有十分重大的结果。

@A1:snyk 吧,iac 测试也不好做

@H8:国内用 IaC 的如同不多,不太风行唉~

@P16:IaC 有不少开源工具,用起来还挺不便的

正文完
 0