腾讯云开发者
订阅
腾讯云官方社区公众号,汇聚技术开发者群体,分享技术干货,打造技术影响力交流社区。
腾讯云开发者微信公众号二维码
关注该公众号

会员可查看最新的全部文章

^__^ 11 / 28
程序员问大师 后台开发,技术真的重要吗?新晋大厂校招生向大师请教: 面试全是分布式、高并发、多线程,上班却成了对需求、写文档、梳理业务、修告警。排查线上故障靠的是看监控、查配置、扩机器;mentor能接手十年屎山,也是靠熟悉拓扑、可观测性、稳定性、排期、拒绝不合理需求,而不是多线程编程的炫技。 后台工作是不是根本体现不了技术?为什么面试又问那么多?工作中如何提升技术?一个优秀后台工程师到底该长什么样? 大师答: 十五年前的自己,也是在各家大厂对接做业务,一样觉得工作没技术,一样焦虑,靠跳槽寻找更技术的岗位,结果发现到哪都在做类似的事。 三年跳槽三次后,突然意识到:自己在别人眼里恐怕成了好高骛远、浮躁、不够踏实的年轻人,惊出了一身冷汗。 大师从此悟道:上进心没用,上进的手脚才有用。 想做核心技术,先得让别人相信你有成为核心的潜力。人生是长跑,先把事做好,机会自然会来。 后台技术当然重要,但你现在做的只是系统的表层工作。 真正的技术价值是在稳定性、成本、性能、架构演进这些大场景里体现的,而那些位置不会一上来就给新人。 当你走到核心项目核心环节,自然就不会怀疑技术的重要性。 那工作中怎么提升技术? 1. 实战永远第一。 主动争取有技术含量的项目,在大项目里成长最快。 2. 小需求也能练技术。 即使业务需求,也可以思考稳定性、性能、成本的极限,把能不能更好当成习惯。 3. 深挖每个不懂的点。 查资料、写总结、写代码验证、做压测量化。 不是懂了原理,而是我知道这个优化能快多少、稳多少。 4. 多交流。 向同龄人学方法,向前辈学路径。 什么样算优秀的后台工程师? 大师说:形态不止一种。 有的专家只盯项目最硬核的一小块; 有的负责架构、稳定性、成本、性能,用专业能力带着团队解决大问题。 先确定你想成为什么类型,再反过来补你缺的那部分能力。 技术也好,沟通表达也好,向上管理也好,都是为把关键的事做好服务的。 技术信仰可以有也很必要,但职场最重要的是:把事办成。 那么,你悟道了吗?
^__^ 11 / 21
浅谈降本增笑背后的高可用困局 2025年对技术团队不算平静。降本增笑、P0故障频繁登上热搜。表面原因看似多样,但这些因素往年也存在,并不会只在今年集中爆发。真正的问题,是高可用建设背后的结构性挑战。 系统质量难以稳定,首先来自熵增。赶工、堆需求、技术债累积、新技术不断加入,都在让系统变得更复杂。理论上通过规范和流程能改善,但现实中业务压力通常远大于质量压力,技术团队很难真正阻断系统滑向混乱。 第二是墨菲定律。只要系统在运行,意外就是必然:机房会坏,链路会断,软件和系统都有 bug。就算做了多活,真正需要切换时也可能失败。高可用是一场永远无法完全取胜的竞赛,只能尽可能延缓系统走向失控。 更麻烦的是,那些把隐患提前消灭的工作,往往看不见、量化不了;但系统一旦撑不住,重构、多活、混合云这些工程就会立刻成为重点。你一年修一堆细碎问题,年底材料并不好看;隔壁团队虽然出过P0,却因大刀阔斧做架构升级,轻松拿到亮眼结果。 高可用做得越早、越细,越难被证明,这也是行业里最吊诡的部分。公司层面也面临同样矛盾:平时的投入看起来琐碎;真正出事故,又觉得当初投入不够。于是形成普遍循环:系统退化 → 重大事故 → 大规模治理 → 阶段稳定 → 再次退化。 高可用像一场反复上演的运动式工程,谁撞上谁倒霉。有没有破局?从工程角度看,没有快速有效的解,很多团队能做的只是避免成为那个倒霉蛋。但如果希望系统长期更稳,关键不在技术,而在组织文化。 至少有三件事值得坚持: 第一,把高可用视为持续工程。 系统健康像身体健康,需要常态维护,而不是一次性升级。给团队留出质量时间,比突击式治理更可靠。 第二,接受高可用是慢变量。 隐患处理不会立刻带来收益,但能减少灾难级事故,也能让系统不至于一路滑向深渊。 第三,坚持体检。 一年小复盘,两年大盘点,即便无法避免事故,也能把12小时的损失降成2小时,这对业务影响是本质差异。 高可用的难点不在技术,在于组织能否给系统留出生长和修复的空间。 下次老板再问你高可用,就把这篇文章甩给他吧!