热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

我这几年踩过的十个坑,每一条都是血泪教训

“阅读本文大概需要3分钟。”一、不记录程序部署在哪里“我:他妈的,这个程序明明一直在正确产生日志,可它到底运行在哪里?怎么我

阅读本文大概需要 3 分钟。

一、不记录程序部署在哪里

我:他妈的,这个程序明明一直在正确产生日志,可它到底运行在哪里?怎么我把所有服务器都翻遍了还是找不到他?

我维护了 60 多台服务器,理论上,我把他们分成了多个组,每个组部署不同功能的程序。可是有一天,当我要找某个程序的时候,我发现它不在它应该在的那个组中的任何一台服务器上面。但是它确实每小时又都在定时跑。那么,它到底在哪里跑?

部署程序时,一定要有一个地方记录每个程序部署在哪个服务器上。无论你是用记事本来记录,还是用各种软件来自动化记录。否则时间久了,程序多了以后,你很难再找到这个程序。

二、报警消息不写明这个报警来自谁

报警:MongoDB 查询失败!

那么问题来了,这是哪个程序报的警?

如果程序需要发送报警消息,一定要在报警信息中写清楚自己是哪个程序,这条警报从哪里发出来。

三、随意给出不重要的数据库删除权限

组员:老板,我刚刚不小心把 xx 表删了。我本来想删除我电脑上的测试环境,没注意到我在操作线上环境,不小心把线上环境的这个表给删了。

我一直认为,我们组的工程师都非常有职业道德,不会做出删库跑路的事情。而且这个环境保存的数据都是可以公开的,不怕被窃取。直到有一天一个下属来跟我说他不小心删了一个保存重要配置数据的表。于是我们花了很久来还原里面的爬虫配置。

收紧权限,对于保存爬虫数据的库而言,即使里面的数据可以随意被组员查看,也不能随意给出删除权限给组员。现在我们的爬虫库只有增加、查询、更新的权限,没有删除权限。

四、用文档来约束数据

我:怎么你重构以后,这个字段不见了?

用 MongoDB 的时候,不需要限制字段的类型,这固然可以加快开发,但是后期做 ETL 的时候,读数据库并对数据进行处理,此时依然会需要依赖字段的格式。

如果只是口头跟人约定好,某某集合里面的字段名分别叫做 aa,bb,cc,格式分别是 int,str,float……也许第一次开发的时候完全满足,但是后面重构的时候,可能某个字段的格式就变了。

MySQL 虽然死板,但是用数据库的机制来约束,可以保证 ETL 程序读到的数据,字段和格式始终如一。程序比人可靠。

五、大量报警

一天收到几千封报警邮件。于是我一封都没有去看。

在设计报警规则和阈值的时候,一定要确保只有真正需要你看的消息才报警。报警功能要做好,只报需要报的内容。否则,当你被报警淹没的时候,报了也白报。

六、阻塞式等待,一睡不醒

我:明明有数据,为什么就是读不出来呢?诶,重启一下就好了。

无论是 Redis 还是 Kafka,我都遇到过在阻塞式等待时,一开始由于没有数据,阻塞等待了十几个小时;然后数据来了,但程序却死在那里了,无法正确读出数据。必须重启才能恢复。

七、Kafka 的 group_id 乱起名字

今天调试这个问题,group_id 写成:xxx_dev;明天调试那个问题,group_id 写成:xxx_dev_2……很多天以后,上次调试某某问题,我用的是哪个 group_id 来着?

在给 Kafka 的 group_id 取名字的时候,名字需要有意义,并且易于分辨。否则后期 group_id 太多以后,你都不知道哪些是做什么用的了。

八、用 IP去链接服务

运维:这个接口的宿主机出现了内存泄露,马上就要爆炸了,我们需要重启一下。

我:不能重启啊,我这边好几个线上服务都强依赖它。

无论是实体服务器还是云服务器,机器都有可能需要临时关停,此时如果使用域名,那么你完全可以重新搭建一个新的接口或者服务,切换域名到新的机器上,再关停原来的服务。这样就不会影响依赖这个域名的其他服务。

九、用文件来记录配置信息

运维:你这个代理转发服务必须迁移到另外一台机器上。

我:可是我所有的爬虫都依赖这个转发服务啊,你给我三个小时,我去把所有爬虫里面的转发服务的地址都改成新的。

有时候,某些服务必须使用 IP,或者域名无法切换,那么,当你用文件来写配置的时候(例如 Scrapy 把代理转发服务的网址写到 settings.py 文件里面)。遇到修改配置,你就不得不去修改每一个程序,然后重新部署。

如果一个配置信息被多个地方使用,那么使用 Apollo 这种配置中心是更好的选择。统一管理所有配置,需要修改配置的时候,只需要在网页上修改一次,点一下发布,所有使用这个配置的程序自动更新。

十、觉得Docker 隔离环境绝对不会互相影响

我:麻烦帮忙重启一下 xx 服务器,上面有一个容器内存泄露,把宿主机卡死了。

Docker只是逻辑隔离,如果其中一个容器占用太大内存,会撑爆宿主机,导致同一个宿主机的其他容器全部挂掉。所以在部署的时候,一定要分清楚逻辑隔离的优势和弊端。必要的时候使用物理隔离。

推荐阅读

1

Alfred 有多强悍,我写了个一键上传图片的 workflow 来告诉你

2

中国最懒城市,这里的人不想赚钱,只想躺平

3

手把手教学,如何解决 Git 冲突?

4‍‍

用鸿蒙跑了个 “hello world”!鸿蒙开发初体验

崔庆才

静觅博客博主,《Python3网络爬虫开发实战》作者

隐形字

个人公众号:进击的Coder

长按识别二维码关注

好文和朋友一起看~


推荐阅读
  • 网络运维工程师负责确保企业IT基础设施的稳定运行,保障业务连续性和数据安全。他们需要具备多种技能,包括搭建和维护网络环境、监控系统性能、处理突发事件等。本文将探讨网络运维工程师的职业前景及其平均薪酬水平。 ... [详细]
  • 本文详细介绍了Python编程语言的学习路径,涵盖基础语法、常用组件、开发工具、数据库管理、Web服务开发、大数据分析、人工智能、爬虫开发及办公自动化等多个方向。通过系统化的学习计划,帮助初学者快速掌握Python的核心技能。 ... [详细]
  • 科研单位信息系统中的DevOps实践与优化
    本文探讨了某科研单位通过引入云原生平台实现DevOps开发和运维一体化,显著提升了项目交付效率和产品质量。详细介绍了如何在实际项目中应用DevOps理念,解决了传统开发模式下的诸多痛点。 ... [详细]
  • 随着Redis功能的不断增强和稳定性提升,其应用范围日益广泛,成为软件开发人员不可或缺的技能之一。本文将深入探讨Redis集群的部署与优化,包括主从备份机制、哨兵模式以及集群功能,帮助读者全面理解并掌握Redis集群的应用。 ... [详细]
  • 深入解析Redis内存对象模型
    本文详细介绍了Redis内存对象模型的关键知识点,包括内存统计、内存分配、数据存储细节及优化策略。通过实际案例和专业分析,帮助读者全面理解Redis内存管理机制。 ... [详细]
  • MongoDB的核心特性与架构解析
    本文深入探讨了MongoDB的核心特性,包括其强大的查询语言、灵活的文档模型以及高效的索引机制。此外,还详细介绍了MongoDB的体系结构,解释了其文档、集合和数据库的层次关系,并对比了MongoDB与传统关系型数据库(如MySQL)的逻辑结构。 ... [详细]
  • 在项目中使用 Redis 时,了解其不同架构模式(如单节点、主从复制、哨兵模式和集群)对于确保系统的高可用性和扩展性至关重要。本文将详细探讨这些模式的特点和应用场景。 ... [详细]
  • 本文探讨了2019年前端技术的发展趋势,包括工具化、配置化和泛前端化等方面,并提供了详细的学习路线和职业规划建议。 ... [详细]
  • 优化联通光猫DNS服务器设置
    本文详细介绍了如何为联通光猫配置DNS服务器地址,以提高网络解析效率和访问体验。通过智能线路解析功能,域名解析可以根据访问者的IP来源和类型进行差异化处理,从而实现更优的网络性能。 ... [详细]
  • 数据管理权威指南:《DAMA-DMBOK2 数据管理知识体系》
    本书提供了全面的数据管理职能、术语和最佳实践方法的标准行业解释,构建了数据管理的总体框架,为数据管理的发展奠定了坚实的理论基础。适合各类数据管理专业人士和相关领域的从业人员。 ... [详细]
  • 本文详细介绍了 Dockerfile 的编写方法及其在网络配置中的应用,涵盖基础指令、镜像构建与发布流程,并深入探讨了 Docker 的默认网络、容器互联及自定义网络的实现。 ... [详细]
  • 深入探讨CPU虚拟化与KVM内存管理
    本文详细介绍了现代服务器架构中的CPU虚拟化技术,包括SMP、NUMA和MPP三种多处理器结构,并深入探讨了KVM的内存虚拟化机制。通过对比不同架构的特点和应用场景,帮助读者理解如何选择最适合的架构以优化性能。 ... [详细]
  • 优化Flask应用的并发处理:解决Mysql连接过多问题
    本文探讨了在Flask应用中通过优化后端架构来应对高并发请求,特别是针对Mysql 'too many connections' 错误的解决方案。我们将介绍如何利用Redis缓存、Gunicorn多进程和Celery异步任务队列来提升系统的性能和稳定性。 ... [详细]
  • 字节跳动夏季招聘面试经验分享
    本文详细记录了字节跳动夏季招聘的面试经历,涵盖了一、二、三轮面试的技术问题及项目讨论,旨在为准备类似面试的求职者提供参考。 ... [详细]
  • 本文将介绍如何利用Python爬虫技术抓取国内主流在线学习平台的数据,并以51CTO学院为例,进行详细的技术解析和实践操作。 ... [详细]
author-avatar
单纯只是一2502904797
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有