让运维更高效:关于ECS系统事件
阿里云会针对ECS实例发布系统事件,当您收到阿里云计划维护的通知时,可以利用ECS系统计划事件了解与实例相关的计划维护操作,并根据您的业务特性选择合适的时间安排运维操作进行故障转移,减少对系统可靠性和业务连续性的影响。
阿里云会针对ECS实例发布系统事件,当您收到阿里云计划维护的通知时,可以利用ECS系统计划事件了解与实例相关的计划维护操作,并根据您的业务特性选择合适的时间安排运维操作进行故障转移,减少对系统可靠性和业务连续性的影响。
xzutils 后门事件是近年来最具代表性的开源供应链攻击案例之一。本文不是重复介绍漏洞原理,而是从 FreeBSD 维护者的角度,复盘这一事件如何影响系统发行版的第三方软件引入流程。
文章指出,FreeBSD 最终没有受到实际影响,很大程度上来自其重写 build 部分、删除用例代码等工程实践。但作者也坦承,这并不意味着流程无懈可击,尤其是在使用上游签名 tarball、比较 git 内容、运行构建脚本等环节,仍然存在被攻击者利用的空间。
最值得关注的是,文章把供应链攻击的目标从“最终用户系统”前移到了“维护者本人”。如果维护者在本机、非隔离环境中执行下载来的代码或生成脚本,攻击者完全可能先攻破维护者环境,再进一步污染下游生态。
这篇文章适合关注开源治理、发行版维护和软件供应链安全的读者阅读。它的价值不在于给出复杂技术细节,而在于提醒团队重新审视日常维护流程中的默认信任。
本文整理了2024年7月19日因CrowdStrike导致的大规模Windows系统蓝屏事件。由于CrowdStrike更新其Falcon安全产品的配置文件,许多Windows系统出现蓝屏崩溃,影响全球多国的重要业务系统。此事件引发了对安全软件稳定性和供应链风险的反思。作者分析了事件的时间轴、技术原因及对安全产品设计的启示。
随着微服务以及云原生的发展,越来越多的企业都将业务部署运行到Kubernetes中,主要是想依托Kubernetes的可扩展、可伸缩、自动化以及高稳定性来保障业务的稳定性。
然而,Kubernetes本身是一个复杂的管理系统,它既然是作为企业业务的基础设施,其本身以及运行在集群内部的业务系统对于企业来说都变得非常重要。
美团服务运维团队从事前防御、事中处理、事后运营多个阶段探索AIOps在事件管理领域的应用。本文介绍了在各个运维领域中AIOps的赋能场景,详细阐述了每一个运维场景的业务价值以及算法的具体的落地效果。
昨天见识到了一种从没见过的从服务器推送事件的炫酷方法:服务器推送事件server-sent events!如果你只需要让服务器发送事件,相较于 Websockets,它们或许是一个更简便的选择。本文聊一聊它们的用途、运作原理,以及昨日在试着运行它们的过程中遇到的几个错误。
k8s的Event事件是一种资源对象,用于展示集群内发生的情况,k8s系统中的各个组件会将运行时发生的各种事件上报给apiserver 。可以通过kubectl get event 或 kubectl describe pod podName 命令显示事件,查看k8s集群中发生了哪些事件。
apiserver 会将Event事件存在etcd集群中,为避免磁盘空间被填满,故强制执行保留策略:在最后一次的事件发生后,删除1小时之前发生的事件。
“DDD诊所”是Thoughtworks DDD社区的一项活动,通过对同事们在实施DDD过程中遇到的问题进行分析和解答,共同提高开发水平。我们将其中一些典型案例整理成文供大家参考。之后也会考虑在适当的时候将这一形式对外部开放。
我们很难避免在 ECS 系统中相互引用 Entity 。而我对 ECS 模式的使用是鼓励去引用的。为此,我对许多常见依赖引用的模式给了对应的解决方案。
最近的一个 luaecs 开发版本中,提供了一种 Lua 层面的引用方案 :在创建 Entity 时,可以指定一个 table 作为该对象的引用。系统会更新它,让它保持为一个有效的(形如 select 过程中的)迭代器。这样,业务层就可以随时通过它 sync entity 中的数据。
我一直不是太喜欢这个方案,所以一直再考虑不同的解决方法。念念不忘 必有回响。昨天,我尝试了一个新的、更满意一点的方案。
目前,我们用 ECS 管理游戏引擎中的对象。当游戏场景大到一定程度,就需要有一个机制来快速筛选出需要渲染的对象子集。换句话说,如果你创建了 100K 个 Entity ,但是只有 1K 个 Entity 需要同时渲染,虽然遍历所有可渲染对象的成本最小是 O(n) ,但这个 n 是 100K 这个数量级,还是 1K 这个数量级,区别还是很大的。
我们的 ECS 系统已经支持了 tag 这个特性,可以利用 visible tag 做主 key 快速筛选可见对象。但当镜头移动时,需要重置这些 tag 又可能有性能问题。重置这些 visible tags 怎样才能避免在 100K 这个数量级的 O(n) 复杂度下工作?
ECS 模式下最难处理的是同类 Component 之间有相互联系的情况。
最方便 ECS 处理的数据是相互独立的,每个数据单元都不和其它数据单元产生联系;如果多个数据单元会有故有的联系时,当可以把它们看作是同一个实体(Entity)下的不同组件(Component)时,那么就可以借用 Entity 的概念来处理它们。我们依旧可以按固定的次序去迭代这些数据。
但是,在复杂系统中,无可避免的,同类数据相互之间也可以产生联系。例如:场景管理中,节点之间有父子关系,计算节点的空间状态的过程对数据的遍历次序有要求。且计算过程还需要访问父节点的状态。解决这类需求是 ECS 框架的一大挑战。