首页 文章 精选 留言 我的

精选列表

搜索[权益保护]，共10000篇文章
优秀的个人博客,低调大师

安全有疆 民用防盗报警撑起家庭安防“保护伞”

随着数字化发展的不断深入，物联网的发展以及通信巨头的介入，极大的推快了探测器无线化发展的前进步伐。报警运营行业这两年也展现出猛烈增长势头，整个联网报警产业链基本处于良性的发展状态，业内人士分析认为，单就开放住宅小区这一政策来说，给联网报警整个产业链带来的发展空间都是不容小觑的。 防盗报警探测技术的融合和创新 防盗报警探测器的性能，是防盗报警系统、乃至整个安防系统运行的关键，虽然目前有众多的技术手段去完善，但受到各技术本身的缺陷、工艺和使用环境等影响，漏报、误报、干扰等仍为用户最为伤心头疼的问题，这需要行业研发制造企业不断地去积累、融合和创新。如被动红外，怎样将人的体温特点、电磁反射特征和生物体、小生物体或非生物体特征进行甄别，以及如何对甄别出来的人或者动物行为进行分析，对此做出准确的判断和预警。目前智能视频复合、生物感应等技术的出现，为防盗报警漏/误报警的缺陷提供了最新的技术解决方案，随物联网、互联网、智能家居的不断普及，防盗报警的应用，将迎来新的发展契机。 防盗报警系统的应用融合 在互联网、智能家居的冲击下，防盗报警不仅仅作为单一的产品功能在应用，在加强家庭、社会安全的同时，将更多地与门禁、对讲、监控、智能家居等行业融合在一起，逐渐脱离传统的单机单功能模式，或成为综合性的智能产品，或成为门禁对讲、智能家居等产品的一项功能。防盗报警器也将重新定义，如添加家电控制模块、生物识别模块、网络模块、视频模块等，融家庭安全、语音通讯、家庭自动化、居住环境监测等多种功能为一体，成为一个新的智能终端入口。如报警主机添加家电控制模块，成为智能家居的控制器，用户通过手机APP、遥控或者电话，可远程控制家中电器、灯光照明、门铃窗帘等；语音识别模块，报警主机整合语音识别等技术，用户通过语音控制一切智能设备，打造极致的用户体验。 防盗报警系统，可以通过单品或套装，实现产品本身的报警功能，如保障财产安全，防盗；保障人身安全，老人求助，防火防泄露防中毒等，并对接接警中心110、120、119；同时可以改善人们的生活质量，如PM2.5检测，家电智能控制，语音对讲，生物识别等，还可以进行平台化运作，提供更多的增值服务。如通过平台，报警器用户的手机APP，不仅可以及时收到报警信息，还可以收到物业通知，能预约挂号、电影订座、网上购物等，打造智能社区，为人们生活提供贴身的便捷服务，成为真正的智能安全生活管家。 民用防盗报警器的应用现状 目前，防盗报警主要在政府部门、金融、文博等领域应用比较深入，而与民众生活息息相关的领域尚处在蓄势待发阶段，如家庭防盗报警、店铺防盗报警、工厂企业防盗报警等，并没有得到好的普及，其主要原因在于民用报警器产品技术未能获得新突破，准确率未得到有效提升，用户使用的便捷性未有极好的改善，从而导致国内防盗报警器产品在功能上、使用上、外观上同质化严重，在中低端市场，因探测精度的不足和应用上的不足，易用性与智能化不够，误报率高散失了用户信心，而在高端应用市场上，基本被国外品牌所垄断，同时智能家居、视频监控、楼宇对讲等产品，以及创客产品，融入了报警功能，使得防盗报警器产品的发展空间越来越小，使其必须在应用上创新，模式上创新，才能在安防领域占有一席之地。 乘借政策的东风，如建设部对智能化住宅小区的六项要求，住宅小区设立计算机自动化管理中心，水、电、气等自动计量、收费；住宅小区封闭，实行安全防范系统自动化监控管理；住宅的火灾，有害气体泄漏实行自动报警；住宅设置楼宇对讲和紧急呼叫系统；对住宅小区关键设备，设施实行集中管理，对其运作状态实施远程监控。安防防范和报警等都纳入小区建设的必备项目。在深圳，禁止安装防盗网，在上海、广州、温州、南昌等地，更是花费重金拆除了防盗网，规定其防盗功能必须由电子防盗系统来完成，这为防盗报警行业的发展带来了新机遇。 而同时，互联网的到来，使得各行各业发生了翻天覆地的变化，一些互联网企业跨界开始进入民用报警市场，从产品的工业设计和用户体验上下足功夫，促使传统防盗报警企业在“风口”上进行颠覆式创新，与物联网产业链的企业互联互通，简化操作、强化用户体验。目前的防盗报警产品，基本可实现一部手机知晓和控制家中所有，报警主机，不仅可对接红外探测器、门磁、烟雾探测器、燃气探测器等，以及接警中心，并融合高清视频监控，实现提前预测并实时查看，并可以联动控制家电，让普通家电智能化，PM2.5检测，改善家居环境等。 民用防盗报警的市场突破 在城市里，一些犯罪分子频频把魔爪伸向居民住宅、单位和商铺，进行入屋盗窃和抢劫，在一些高端社区，虽然有门禁系统、监控系统、周界防范、保安值守，但被盗案件依然时有发生。媒体曾报道，南京某小区同一天上午连续发生2起入室盗窃案件，居民家中被盗现金、珠宝等财物近20余万元，通过监控，查看到嫌疑人在短短40分钟的时间内，就完成进出小区、寻找目标、并打开两家的防盗门这一系列繁琐的动作。调查中发现防盗门对于小偷而言，掌握了技术性开锁后，开锁仅需几秒，如同使用自家的钥匙开锁一样，民用防盗报警的使用迫在眉睫。 在现实中，我们看到很多商铺、小区楼盘、工厂企业，防盗报警系统使用率并不高，而实际上，人们对于安全的需求是迫切的。防盗报警如何打开民用市场，这需要产品本身足够贴合实际，作用让人信服，需要运作服务模式上有新突破，根据用户的类型特点、生活方式，打造不同的解决方案，以满足民用家庭、店铺的需求。 如与社区、物业合作，一方面可以共同开展宣传活动，举办安全讲座，进行产品的深一步体验等，另一方面可以在设计安装、售后维保服务的同时，对物业监控人员、保安人员进行专业培训，提升其使用维护的技能，让报警服务切实保障人们的生命财产安全，真正的飞入百姓家。同时，还可以与社区O2O服务运营商进行合作，如通过社区O2OAPP，业主可以方便在线联系物业管理处，及时接受物业通知、查询物业水电费，智能开门，在线报修等；物业人员可与业主在线沟通，发布物业通知，及时响应业主的报修，设施预警；还提供高效的访客通行验证，智能门禁配置管理。目前，各种类型企业都加入到了分食社区O2O这块“大蛋糕”的行列，万科、中海、保利等将物业管理当作重点发展的新板块，彩生活、实惠等模式创新，也备受市场青睐。 防盗报警器通过一套打通线上线下的平台化系统，让每一位居民的生活联通起来，智慧起来，即让用户使用后，便有离不开的感觉，除将安全关联外，还将家庭电器、生活环境相关联，将日常生活需求相关联，通过具有综合的服务平台，整合资源，为用户提供综合的服务支持，构建新的防盗报警服务应用模式，出现民用监控一样的免费模式，这也许是未来防盗报警行业的新思路。 民用防盗报警产品，需冲破已有界限，在联动应用性上，打造出难以复制的核心功能，让人们生活更安全、更便捷、更智能，打动用户。 本文转自d1net（转载）
2017-07-03
优秀的个人博客,低调大师

苹果iOS 10系统“激活锁”绕过漏洞,丢失保护功能形同虚设?

本着求真和好奇的心态，此次宅客频道将带领读者们讲述此次事件的来龙去脉、破解流程以及相关细节，试图将完整的故事呈现给读者们，让读者了解到： 漏洞是什么，可导致何种后果？ 这个漏洞最早是如何被发现的? 复现漏洞的具体步骤是怎样的? 我们是否会受影响，该怎么做? 该漏洞有何后果？ 从iOS 7开始，苹果设备就具有一项“激活锁”功能， 当用户的设备不慎被偷，只要激活"丢失模式”（Lost mode），盗窃者在没有得到合法机主许可就无法激活设备到正常工作状态，这使得丢失的苹果设备很难被直接转卖，不仅提高安全性还降低了失窃率。 这也是许多人在丢失苹果设备后都收到钓鱼短信及邮件的原因——盗窃者试图骗取APPID账号密码来解锁设备。 然而，此漏洞的出现，意味着任何人都可以绕过“激活锁”直接重置该设备，让丢失模式形同虚设！盗窃者可以利用该漏洞将一些非法获得的设备直接解锁后重新售卖或自行使用。简而言之，当你的设备丢失，你更难将它找回了。 那么这个漏洞是如何被发现的呢？ 据外媒报道，该漏洞最早是由印度安全专家赫门特·约瑟夫（Hemant Joseph）发现的，于是宅客频道（公众号：宅客频道）通过博客了解到破解的全部操作流程。 iOS 10.1漏洞发现，源于被坑的购物经历 赫门特给朋友网购了一个iPad，哪知设备刚到手，却发现被开启了“丢失模式”，发现连接WiFi之后，设备会要求输入之前机主的APPID账号密码。赫门特这才知道，自己花了许多时间挑选iPad，最后却买回来一块“砖头”——他觉得自己被彻头彻尾地耍了，简直不能忍！ “自己动手，丰衣足食”，作为安全专家的赫门特决定发挥自己的聪明才智对iPad进行破解，他立刻想到了让设备缓冲区溢出的方法。 以下为赫门特个人博客中对破解过程的描述： 我在WiFi网络选项中，选择“连接另一个网络”。 跳转到一个要求输入用户名的登录框。 以上只有一个输入字段，如果有字符限制的话，比较难引发内存缓冲区溢出。但如果点击“安全选项”，选择安全协议WEP，就有另一个WPA WPA2企业版的选项出现。 我选择WP2企业版，这时会出现三个输入框：名称、用户名和密码，然后我很惊奇地发现，这里居然没有限制字符长度，可以肆无忌惮地输入，真是太适合用来造成内存缓冲区溢出的情况了！ 一直复制粘贴输入字符，直到设备卡住。 我等了一会儿，看看是恢复正常还是软件崩溃，结果既没有崩溃也没有恢复，一直卡着。又等了一会，我按下了解锁按钮，结果它把我带回到一开始的欢迎屏幕了 :( WTF ？（心中一万头羊驼奔过） 第一次尝试破解失败后，赫门特没有放弃，开始第二次尝试： 思考了一会如何诱发程序崩溃让它跳到主屏幕上，我想到了利用iPad外壳（iPad smart Case）的自动唤醒功能来试试，因为可以利用它的这个特性：当我们用盖上外壳盖来关闭屏幕，再打开外壳盖，它会重现之前关闭之前的屏幕，继续刚才的工作请求。 于是我重复了刚才的操作，在最后一步iPad卡死的时候，盖上外壳盖子，然后过一会儿再打开。 过了大概20~25秒，iPad出现了软件崩溃，然后把我带到了主屏幕，从而绕过了所谓的“激活锁”，成功！ 由此可以看出，这里出现的漏洞的主要原因在于：连接WiFi时的输入框限制输入字符的长度，而在实际使用当中，没有人会使用一个超过1000个字符来当账号或密码。 看到这里，可能有些读者已经想找一台iPad来亲身体验一把了，不过你们可能不会成功，因为发现该漏洞的印度专家赫门非常耿直，发现漏洞后立马写邮件告诉了苹果官方，并很快得到了苹果官方的回复。 苹果很快推出了iOS 10.1.1 的版本更新，修复了该漏洞，因此该漏洞只可能在iOS 10.1 或者更早的版本中复现。 然而，“绕过风波”并没有就此结束。 研究员不依不挠，新版本仍能被破解 Vulnerability Lab实验室的研究人员也对此问题进行分析后，发现利用屏幕旋转和Night Shift（自动调整屏幕色温）功能可在iOS 10.1.1系统中重现这个漏洞。 他们提供了一段成功破解的视频： 宅客频道发现，在视频演示中，主要区别于破解iOS 10.1绕过漏洞的地方主要在于： 输入的字符使用了emoji表情等特殊字符 在最后一个中反复使用了智能外壳和屏幕旋转功能 需要很精准地把握好关键操作的时间点：在某个瞬间设备会出现不到一秒的主屏幕，这时需要适时按下Home键才可以完全绕过激活锁，这一时机很难把握。 宅客频道编辑找来了一个装载iOS 10.1.1系统的iPad mini 2 , 尝试复现该漏洞，但不知是由于没有把握好时机，尝试多次后并没有成功解锁设备。然而在国外社交媒体上有网友表示自己按照视频演示，成功破解了iPad mini 2（同样尝试了好几次）。 目前，宅客频道还没有发现任何成功利用此方式破解iPhone设备的案例。在国外一名研究员安德鲁·坎宁安的报道中，他也发现了相同的情况： 根据这个视频，我们能够在运行iOS 10.1.1的iPad Mini 2上重现该问题，然而在我们的测试中，我们无法在运行iOS 10.1.1 的iPhone 5设备中重现这个bug，在实验中，iPhone没有向iPad那样旋转为横屏模式，也没办法用智能外壳来控制屏幕的开关。 由此看来，该漏洞在iPad上也需要一定的技巧才能复现，而在iPhone上几乎无法实现，因此人们其实并不必为这个漏洞太过担心，并且相信苹果公司也将会在接下来推出的iOS 10.2的版本更新中修复该问题。 我们该怎么做？ 针对此问题，国外相关安全机构给出了一些建议： 当苹果为这个错误提供了一个补丁后，尽快安装它。 日常苹果设备丢失，对方可能不会去恶意破解，但尽可能为之设置一个安全的PIN码或锁屏密码，以确保安全。 不过对于此次“激活锁”绕过漏洞，宅客频道有个更直接有效的终极建议：看好你的机器设备，别把它弄丢了。 --------------------------- 查看 --------------------------- 文件 "lantern.exe" 已修改。 您希望在压缩文件里更新它吗？ --------------------------- 是(Y) 否(N) 取消 --------------------------- 本文转自d1net（转载）
2017-06-04
优秀的个人博客,低调大师

🔥 赋予 AI Agent “无限续航”：语义保护型上下文压缩技术解析

想象一下，你正在指挥一个超级聪明的AI助手（我们称之为Agent）帮你完成一项复杂任务，比如策划一次跨国旅行。一开始，它记得你的所有要求：想去哪些国家、预算多少、喜欢什么类型的酒店。但随着任务的进行，它需要查询航班、比较酒店、查看天气……每一次查询和思考都会增加它的“记忆负担”。 如果它“记性”不好，聊到一半就会忘了最开始的要求，或者陷入混乱的逻辑中，这就是开发者常说的“上下文窗口爆炸”问题。 Solon AI 框架里有一个秘密武器——SummarizationInterceptor（智能记忆压缩器），它能让AI助手像人一样，既不会忘记初心，又能轻装上阵，实现真正的“无限续航”。它不是简单粗暴地“断片”，而是一套优雅的“记忆管理大师”。 1、为什么不能简单粗暴地“断片”？ 处理长对话，最直接的想法是：对话太长？那就删掉前面一半吧！但这种“暴力裁剪”对AI来说，会带来两个致命伤： 忘本（失去初心）：AI Agent 最开头的系统设定和你交给它的第一个任务，如果被删掉，它就会像无头苍蝇一样，完全不知道自己要干嘛了。 断片（逻辑断层）：AI Agent 的工作模式通常是“思考 -> 行动 -> 观察结果”（ReAct）。如果你恰好把它的某个“行动”和对应的“观察结果”给拆散了，它看到结果却不知道为什么会有这个结果，逻辑瞬间混乱，甚至陷入死循环，无法自拔。 所以，忘记也是一门艺术，需要有策略地忘记。 2、智能记忆压缩器是如何工作的？ SummarizationInterceptor就像一个聪明的图书管理员，它不会随意丢弃书籍，而是按照一套精密的流程来整理书架。它的工作分为四步： 第一步：锁死“初心”（锚点锁定） 无论后面的对话有多长，管理员都会第一时间找到两样东西并永久保留： 任务指令：你第一次给AI布置的任务（UserMessage），这是它的“初心”。 基本守则：AI的系统设定（SystemMessage），这是它的“行为准则”。 这两样东西被牢牢锁定，确保AI永不迷失方向。 第二步：禁止“断片”（原子对齐） 这是整个机制最核心的“黑科技”。当管理员决定要清理一部分旧内容时，他不会直接动手。他会仔细检查，确保永远不会把“行动”和“结果”这对“连体婴儿”给拆散。 智能检查：如果发现准备清理的起点正好落在一个“观察结果”（ToolMessage）或者一个“行动指令”（AssistantMessage）上，管理员会立刻把清理起点向后挪，直到确保每一对“行动-结果”都完整地保留下来。 第三步：让记忆更连贯（语义补齐） 为了让你和AI的对话读起来更通顺，管理员还会再多做一步“人情味”的检查。如果清理后的第一条记录是一个“行动结果”，管理员会看看它前面是不是紧跟着一条AI的“思考过程”（Thought）。如果是，他会把这条“思考”也一并留下。这样一来，AI看到的历史永远是从一个思考片段开始的，理解起来更自然。 第四步：贴个“便利贴”提醒（断裂感知） 在永久保存的“初心”和压缩后的“最近记忆”之间，管理员会贴上一张醒目的“小贴士”： --- [系统提示：中间部分历史对话已优化压缩，请根据当前计划和剩余历史继续任务...] --- 这张“小贴士”非常重要，它用AI能理解的语言告诉它：“别担心，中间有些细节我帮你精简了，你专注眼前的任务和核心目标就好。”这能有效防止AI因为记忆断层而产生困惑和幻觉。 3、如何实现“无限续航”？ 通过这套“记忆管理术”，SummarizationInterceptor 把AI的内存变成了一个动态的“新陈代谢系统”： 内存恒定：无论AI运行了10步还是1000步，它一次“思考”所需要处理的信息量（Token数）始终维持在一个安全的范围内。 逻辑清晰：因为“原子对齐”机制，AI看到的每一段记忆都是完整的“思考-行动-反馈”闭环，逻辑链条非常稳固。 目标永存：“系统设定”和“用户任务”这两大核心目标永远在线，AI永远不会忘记“我是谁”和“我要去哪”。 4、更强大的组合：插件式的记忆策略 这个“记忆管理器”最妙的地方在于，它采用了策略模式，就像手机可以安装不同的APP来扩展功能一样，你可以给它接入不同的“记忆处理插件”。框架已经为我们准备了几款强大的插件： 层级压缩器：它会像滚雪球一样，把旧的记忆摘要和新的对话历史不断融合、压缩，生成一个始终更新的“全局进度摘要”，让记忆像洋葱一样层层包裹，永不丢失核心。 关键信息提取器：它像一个信息审计员，只从对话中提取最核心的“干货”，比如用户要求、获取到的数据、已经失败的尝试等，过滤掉那些啰嗦的思考过程。 向量库记忆师：它会将被清理的详细对话“归档”到一个巨大的知识库里（向量数据库）。当AI需要回忆某个细节时，可以通过一个专门的“召回历史”工具，像用搜索引擎一样把它找回来。 你可以把这些插件组合起来使用，比如先归档，再提纯，最后压缩，打造一个最适合你AI助手的记忆管理方案。 应用示例： import org.noear.solon.ai.agent.react.ReActAgent; import org.noear.solon.ai.agent.react.intercept.SummarizationInterceptor; import org.noear.solon.ai.agent.react.intercept.summarize.*; import org.noear.solon.ai.agent.session.InMemoryAgentSession; import org.noear.solon.ai.chat.ChatModel; CompositeSummarizationStrategy compositeStrategy = new CompositeSummarizationStrategy(); compositeStrategy.addStrategy(new KeyInfoExtractionStrategy(chatModel)); compositeStrategy.addStrategy(new HierarchicalSummarizationStrategy(chatModel)); SummarizationInterceptor summarizationInterceptor = new SummarizationInterceptor(12, compositeStrategy); ReActAgent agent = ReActAgent.of(chatModel) .defaultInterceptorAdd(summarizationInterceptor) .build(); 5、总结 SummarizationInterceptor的设计哲学是：有尊严地裁剪，有逻辑地遗忘。 它不仅仅是一个节省计算资源的工具，更是AI能够保持逻辑连贯、处理超长复杂任务的“护航者”。有了它，开发者可以放心地让AI助手去处理那些需要几个小时甚至几天才能完成的、真正复杂和智能化的工作，而不用担心它会中途“失忆”或“精神错乱”。
2026-02-19
优秀的个人博客,低调大师

【保护你的上线】风险治理的防范与排查之路 | 京东云技术团队

前言 项目研发的过程中经历了需求评审、开发评审、代码编写、测试用例评审、项目测试、产品和UI验收等一系列流程，其中投入了大量的人力和精力。 然而最后的上线阶段，总是存在诸多不确定性和可变性，往往在测试阶段测N次都没有丝毫问题，一上线就会出现Bug（简直是墨菲定律的诅咒）。 经过多年的经验总结和残酷教训，我们将这些已知的或潜在的风险点详细梳理出来，希望每个项目的上线都可以踏踏实实、万无一失、顺顺利利。 本文，我们将从三个方面来防范上线风险：操作防范、双岗&自查、监控告警。 一、操作防范 主要包含了四大类别的防范：研发防范、配置防范、运维防范和审批防范。 1.1研发防范 1.1.1 通用层 1. Loading/Confirm统一标准化 2. 错误页/骨架屏/无数据/网络异常兜底规范 3. 公告、弹窗规范 1.1.2 代码层 1. 使用https、禁止非jd源、验证外网可用 2. 环境切换通过系统变量区分 3. Commit规范 ▪ 单次提交独立功能代码 ▪ 所有研发代码提交Coding 4. 统一IDE和脚手架 5. 开发环境node.js、npm、joyer、taro等版本统一 6. 统一通用组件 ▪ 沉浸式导航 ▪ 共用组件，检测版本支持及容错处理 ▪ 云梯组件 ▪ 加密防刷：AKS，AAR ▪ 风控设备指纹 ▪ 奇点埋点 ▪ 下载唤起组件 ▪ 分享组件以及金口令 7. 数据处理 ▪ 分页加载避免请求死循环 ▪ 网关层错误码处理 ▪ 服务端接口层错误码处理 ▪ 主功能接口异常是跳转错误页/弹窗重试等必要处理 ▪ 兜底方案 1.1.3 UI层 1. 是否有动效 2. 音视频是否兼容性 3. 是否存在性能卡顿 1.1.4 安全层 1. 编码问题：是否通过eslint 2. 兼容问题：编码语法、方法属性、组件库最低支持版本等处理 3. 逻辑功能：代码逻辑是否与预期功能一致 4. 异常情况：是否考虑降级/容错/超时等异常情况 5. 用户体验：新增或者修改功能对性能或者体验是否不良用户体验影响 6. 安全：密文传输、防刷、脚本注入等 7. mock：是否正确处理了mock数据的展示 8. 敏感数据：对数据处理是否存在潜在客诉风险等 1.2 配置防范 1.2.1 研发配置 1. 内容配置平台配置已上线的配置再次操作要注意不影响线上，尽量新增配置 2. 配置数据类型不支持时间控件，禁止在上面配置时间或时间戳等数据 3. 配置前的数据校验（例如：链接格式是否正确，数据长度是否需要限制等） 4. 数据容错处理，若为重要数据需设置为必填项 "required": true； 1.2.2 运营配置 1. 活动上线前，所有生产配置必须都完成 2. 已上线的配置，再次操作需与产品及研发确认；运营内部双岗确认 3. 预发环境验证，数据和生产保持一致（奖品类型、券类型、秒杀时间、任务类型等) 4. 奖励、券或任务等需验证可正常发放或领取后再配置展示到前端 5. 在活动领取利益点到其他活动页使用，需保证二级活动页面内使用利益点正常 1.2.3 环境配置 1. 所有新项目统一使用joyer脚手架初始化 2. 命令统一，本地环境、打包、发布各环境等 3. vconsole、注释等仅在非生产包中配置 4. 每个项目必须有mock环境，使用mock数据去验证各类情况，而不是修改或注释代码 5. 老项目是否采用webpack、vue-cli统一规范 1.3 运维防范 1.3.1 域名解析操作 1. ip是不在应用下存在 2. 实例上是否具有可访问项目 3. 找运维配合查看是否项目可访问 4. 确保告知运维工单受理通知开发人员及时验证 1.3.2 CDN操作 1. 确保源站域名和加速域名不一致 2. 确保上传的加速内容与分发方式相匹配（图片、大文件、视频、直播流） 3. 确保加速域名下的文件为静态资源（考虑是否需要做动静分离） 4. 确保源站IP是否正确 5. 申请接入后只代表CDN已完成后还注意需配置DNS解析变更 6. 查询输入域名查看全国各地区解析是否生效 1.3.3 HSTS操作 1. 确保客户端或应用是否https或开启https强跳是否有问题 2. 对于vip下有多个应用或域名要通知各方确认是否有影响 1.3.4 http2操作 确保域名为https才可开启 1.3.5 ddos操作 CDN域名暂不用接入 1.3.6 扩容操作 1. 机器审批完成确认执行结果全部成功 2. 确保新扩容机器配置及项目部署 3. 对于混合部署有多个应用存在需要所有应用都完成部署并验证（可让运维配合） 4. 混合部署应用确保每个应用都要走复用工单 5. 确保扩容操作完成后重启机器操作 1.3.7 缩容操作 1. 确保CDN域名解析的为内网VIP（如果为rip需要走变更VIP工单流程） 2. 混合部署确保每个应用都要走工单 3. 预发机器需要补充预发域名反向代理变更工单 1.3.8 下线操作 1. 确保下线机器是否影响线上（独立部署某个项目） 2. 注意摘流量-摘机器等步骤完成才可下线 1.3.9 回滚操作 1. 使用JDOS点击回滚操作 2. 回滚选择的包要仔细检查是否是上次上线的 1.3.10 堡垒机操作 1. 容器必须正常启动 2. dockerfile构建的镜像，只能申请root权限且22端口必须打开 3. 公共镜像，只能申请root权限且22端口必须打开 1.4 审批防范 1. 是否经过测试节点审批 2. 是否由leader审核 3. 开发与审批权限是否分开   二、双岗&自查 上线前的双岗自查，是我们制定的一项标准流程。要求研发人员在上线前必须按照下面的清单，并寻求其他同事的协助进行项目代码的排查（当局者迷，旁观者清）。 2.1 前端 2.1.1 环境检查 1. 域名是否接入CDN 2. jen配置是否一致 3. jen是否全部在线 4. 是否开启gzip 5. 部署机器数量与预期是否一致 2.1.2 公用组件 1. 是否接入AAR 2. 是否接入AKS 3. 是否接入风控 4. 是否添加SGM监控 2.1.3 需求检查 1. 本次上线资源是否包含非本次产品需求迭代内容 2. 页面引入资源是否都是本次上线内容 3. 本次上线资源是否为预发已测试版本 2.1.4 代码检查 1. 是否有第三方代码注入 2. 是否存在敏感字段 3. 是否去掉log/mock/Vconsole等调试工具 4. 项目中是否存在http域名资源 5. 服务端接口是否为线上 6. 检测所有资源域名是否为线上外网域名 7. 包资源文件hash是否由生产部署 8. 仓库master代码是否是最新的 9. 对于混合部署应用，本次上线是否只更新当前应用代码 10. 对于通天塔自定义组件，本次改动是否考虑低版本，是否影响其他项目中引用的模板 2.1.5 回归检查 1. 使用4G/5G验证 2. 上线后操作CDN资源是否是最新上线的 3. 上线后验证。对于混合部署的项目，最新分支是否合并到master 2.1.6 流程工单 1. 双岗检查确认通过 2. UI走查通过并确认 3. 风控验收通过并确认 4. 安全测试工单提交并完成 2.2 服务端 2.2.1 监控检查点 1. 业务监控 ◦ 订单 ◦ 日志异常 ◦ SQL异常 ◦ SQL耗时 ◦ 业务耗时监控 ◦ 业务状态异常监控 ◦ 异常流程监控 2. 基础监控 ◦ 第一类运维：应用系统所依赖的硬件、虚拟机、网络等 ◦ 第二类运维：操作系统层面，比如cpu,内存，硬盘，IO等 ◦ 第三类运维：中间件层面的，比如数据库，缓存，tomcat, ningx等 ◦ 第四类运维：应用本身的，比如JVM监控, 日志归集等 ◦ 第五类运维：新功能上线操作和日常应急演练工 2.2.2 通用自查点 1. 上线顺序类 ◦ 内部存在多个应用上线，依赖关系及上线顺序，是否已经考虑过 ◦ 应用上线前，是否需先创建好了相关表结构，注册mq，rpc等操作 ◦ 本次版本上线，是否涉及外部应用，是否需要别的模块配合，上线是否有顺序要求 2. 安全类 ◦ 是否要考虑外网安全问题，比如SQL注入，XSS攻击，敏感信息加密，账号爆破等 ◦ 是否考虑接口通信安全问题，加签验签，秘钥管理等 ◦ 各种访问是否考虑要增加白名单或者证书或者短信 ◦ 数据库敏感字段是否加密 3. 防刷，防重类 ◦ 防重机制，哪几种状态和场景下允许重复发送订单 ◦ 否有限制允许同一秒接受多笔同样的订单 ◦ 平台唯一ID生成是否会有重复的可能 ◦ 所有请求入口，定时器和API请求是否使用乐观锁。考虑并发重复处理问题，并且要判断更新影响条数 4. 异常处理类 ◦ 是否处理了各业务的主分支以外的异常分支 ◦ 详细异常栈别吃掉 ◦ 三方交互的是否完成 ▪ 需要抓取IOException做处理 ▪ IOException需要打印URL方便报警排查问题 ▪ 需要设置连接超时和读取超时时间 ▪ 是否需要通过代理出网 ▪ 是否需要再三方添加白名单 ▪ 三方是否有最大数限制 ▪ 合理设置http连接数和关闭连接 5. 日志规范类 ◦ 日志打印是否有自己的业务规范，有助于日志巡检 6. 定时任务类 ◦ 业务定时器是否有浪打浪，重复处理的情况，并发配置是否设置成false ◦ 定时任务中处理的数据量是否有预期的执行size，是否会出现异常情况下，处理的size越来越多的情况 7. SQL类 ◦ 是否使用了唯一索引 ◦ 唯一索引的使用是否正确，例如多个字段做为联合唯一索引，是否存在字段为null情况 ◦ update和select语句是否有预期的执行size ◦ 是否避免使用复杂sql ◦ sql是否检查过执行计划，是否能命中索引，一段时间业务增长是否存在慢sql的可能性 8. 缓存的使用 ◦ 缓存使用，是否设置超时时间，超时时间设置是否正确，是秒单位，还是毫秒单位 ◦ 缓存同步问题解决方案的评估（数据库悲观锁+事物+排序、redis悲观锁、CAS） ◦ 清楚redis的使用场景 9. 事务的使用 ◦ 代码中使用事务的需要考虑死锁场景 10. 管理后台 ◦ 管理后台下载，查询等功能是否有条数限制和频次限制 11. 类型转换 ◦ 类型转换是否正确，是否先判空再进行转化 12. 连接数，线程数 ◦ 线程的创建是合理地否限制了线程数量 ◦ 相关中间件的连接池数量设置是否合理 13. 返回码解析 ◦ 解析响应码是否正确，特别是对于网络异常、catch异常、无此订单等特殊情况 ◦ 响应吗解析-网络异常/订单不存在(网络异常导致和查询早于交易导致)，非明确失败，不可以设置失败 14. 系统设计问题 ◦ 异步转同步，如果后端异步部分组件宕机或重启，导致同步dispatch数据一致被阻塞 ◦ 是否存在单节点 ◦ 是否要支持分布式部署 ◦ 乐观锁防止并发修改，悲观锁 15. 超时时间设置 ◦ 任何RPC调用地方是否设置连接超时和响应超时时间,包括HTTP、redis、数据库等 16. 金融属性 ◦ 记账类功能需要考虑余额和流失是否在并发情况下准确 ◦ 金额单位，精度是否正确 ◦ 金额类型转换是否正确 17. 时间写法 ◦ 时间格式，精度是否有问题，是否会出现写库后四舍五入的情况，导致查询不匹配 ◦ 数据库时间配置问题，是否设置东八区，活动是否对时间使用东八区格式 18. 配置文件 ◦ 线上配置文件是否单独抽离上线包，是否已提前在平台单独配置 ◦ 若存在不抽离的配置文件，随代码提交的配置文件，是否已检查是正式环境的配置信息 2.2.3 资源支持项 1. 是否要运营提供额外支持，比如运营后台参数配置等事项 2. 是否要运维提供额外支持，比如配置网络环境、添加证书秘钥、创建文件目录、添加和删除jar包等事项 3. 是否要DBA提供额外支持，比如新增模块添加数据库访问白名单等事项   三、监控告警 监控告警是上线后的风险治理必要机制，一旦出现告警，我们可以第一时间排查和解决，防止更多的客诉产生。 1. RPC层监控 ◦ 超时监控 ◦ 异常报错 ◦ 可用率 2. CACHE监控 ◦ redis连接异常 ◦ r2m可用率 ◦ r2m容量 ◦ r2m主从切换 3. MQ监控 ◦ MQ接收重复 ◦ MQ发送失败 ◦ MQ内处理失败 4. Task监控 ◦ 定时任务未执行 ◦ 定时任务超时 ◦ 定时任务执行异常 5. 业务异常监控 ◦ 获取锁异常 ◦ AKS和防刷未通过异常 ◦ 任务领奖/接取等异常 ◦ 人群没有权限 6. JVM监控 ◦ fullGc日志与告警 ◦ jvm监控告警 7. 容器监控 ◦ 实例存活 ◦ CPU负载&使用率 ◦ 机器内存 8. DB监控 ◦ DB层CRUD执行异常 ◦ cleverBD慢SQL定期巡查 ◦ DB查询操作时间超长 ◦ 线上环境（应用、数据库、配置等）审批负责人是否为当前leader 9. 利益点监控 ◦ 营销发奖失败 ◦ 库存不足 ◦ 活动未开始/已结束 ◦ 被风控 ◦ 防重失败 ◦ 单个用户领取利益数量超过配置的警戒线 ◦ 活动整体发放量超过配置的警戒线 ◦ 其他异常失败 10. 业务响应码监控 ◦ 第三方接口正常码和异常码配置来监控可用率 11. 配置校验 ◦ 获取配置异常 ◦ 配置中该配应配字段未配置 ◦ 配置中字段配置类型异常 ◦ 没有符合当前时间的配置 ◦ 活动已结束但仍然有大量用户访问 ◦ 多个配置的时间点冲突 ◦ 配置的奖励Id/任务Id等在第三方接口未查询到 ◦ 每次运营修改配置，修改项通过告警发送到研发，对告警分等级 12. 活动资格校验 ◦ 绕开某个校验告警 ◦ 应是老用户领奖但新用户通过前置校验进入领奖流程  作者：京东科技 胡骏 来源：京东云开发者社区 转载请注明来源
2023-08-25
优秀的个人博客,低调大师

Google 开源 GUAC，又一个保护软件供应链的项目

自从去年年底 Log4j 漏洞被发现以来，软件供应链的安全问题就是目前很多企业和政府组织非常重视的问题。 此前 Google 就已经针对软件供应链的安全开源了一个名为 SLSA（Supply chain Levels for Software Artifacts）的框架，这是一个新的端到端框架，Google 希望通过 SLSA 能推动标准和准则的实施，以确保整个软件供应链中软件工件的完整性。 SLSA 框架的灵感来自其强制性的内部 「Binary Authorization for Borg」 执行检查器，该检查器可确保生产软件得到适当的审查和授权，特别是在代码可以访问用户数据的情况下。Binary Authorization for Borg 已经在 Google 内部使用了 8 年时间，并且是 Google 所有生产工作负载的强制性检查器。 Google 近日又公开了一个针对软件供应链的全新开源项目，该项目名为 GUAC（Graph for Understanding Artifact Composition），由 Google 与 Kusari、普渡大学和花旗银行合作开发。 这是一个免费的工具，可以将许多不同来源的软件安全元数据结合起来，GUAC 的目的是使软件构建、安全和依赖性元数据信息具有更广泛的可用性，使每个组织都能免费获得这些信息，而不仅仅是那些行业顶尖的企业组织。 此前存在的问题在于，尽管各企业组织目前可以获得软件材料清单、漏洞数据库和其他信息来源，但很难将这些信息结合起来并加以综合，无法获得一个更全面的数据视角。目前 GUAC 还处于早期开发阶段。 GUAC 有以下四个关键功能： 收集：可以配置 GUAC，并将其连接到各种软件安全元数据的信息来源（包括：公开、内部，以及合作的第三方数据来源）。 摄取：GUAC 从其上游数据源导入关于工件、项目、资源、漏洞、存储库甚至开发者的数据。 整理：从不同的上游数据源摄取原始元数据后，GUAC 通过规范实体标识符、遍历依赖树等，将其组合成一个连贯的图表。 查询：对照整理好的图表，用户可以查询附属于图中实体或与之相关的元数据。查询一个给定的工件可以返回它的 SBOM、出处、漏洞和最近的生命周期事件，以及那些与之相关的依赖关系。 目前你可以在 GitHub 上找到该项目的更多信息，该项目还在开发中， 目前并不完善，感兴趣的开发者也能积极参与项目开发。
2022-10-23

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册