运维

最近Model Context Protocol 简称mcp火的一塌糊涂，为了验证一下效果如何。于是我也来部署一个mcp服务体验体验。 客户端选择 客户端目前有很多，主流的一下四款 Cherry St

早上刚到工位，企业微信炸锅了。前端反馈构建失败，于是我火急火燎的打开jenkins Console Output就看到了下面的日志。 我手动解析了一下 registry.nlark.com 没有解析记

在使用async并发请求时。在请求数过多往往会超出系统资源限制比如文件描述符超限。更严重的是会导致被请求服务器端压力过大直接报错。因为使用python的同步原语Semaphore来限制并发非常有必要

很早就像专门写一个专栏来聊聊关于运维如何troubleshooting。后来转念一想其实本来就没有天下第一的武功哪来普世的解决方法。加之我从业时间也不算太长。故就不聊方法论层次的（自我觉得层次不够）。

在容器化实践中部署spring boot应用普遍采用基础java镜像再添加jar包层来构建应用镜像制品。随着公司业务大量上云，每个变更日上传到云上镜像日渐增多，导致本地机房到云上带宽压力倍增。为解决镜