在线应用的诊断一直是日常维护中的难点和痛点，2018年下半年，Alibaba 开源了 java 应用诊断工具 arthas ，让 java 应用的诊断能力上了一个台阶。作为基础架构团队，我们自然也对它非常感兴趣。研究后发现，arthas 确实是一个非常优秀的 java 诊断工具，但是也存在一些不足。 一是 arthas 更像是一个工具，而不像一个产品。如果要使用它，首先要登录相关机器，然后在机器上下载 arthas，再执行一些命令来运行。这整个流程里，下载可能出现问题，运行 arthas 也需要具有目标进程相应的权限，还需要先看看对应进程id等等...这些确实只是一些小问题，但也可以选择让这些问题不存在，让整个使用过程更加流畅。 二是 arthas 缺少 web 界面。命令行界面用起来确实很酷，但不可否认在相当一部分情况下 web 界面更直观更友好，很多需要查文档的情况在 web 界面下都可以直接操作，降低了使用门槛。 三是 arthas 所有功能都针对单台机器，实际上很多时候我们需要考虑和观察整个应用的运行情况，需要一个应用级的视角。 四是 arthas 是一个独立的工具。
基于ClickHouse的Billions2.0日志方案上线后（B站基于Clickhouse的下一代日志体系建设实践），虽然能够降低60%的存储成本，但仍然存在几个比较明显的问题，需要进一步的优化和解决。
也许你经历过这种情况：产品和设计同学用一句话就把需求说完了，你抓破脑袋做出来的版本又达不到他们的要求。不如尝试让 AI 承担痛苦，让它理解、拆解并实现一句话需求？本篇作者尝试提出一个自动配置可视化系统，通过自动生成表单解决上述痛点。欢迎阅读～
云计算发展至今已经有十余年，已从理论演变为企业数字化的必经之路。与其他技术相比，云计算在行业中的应用是有增无减。当前，业务上云已成为国家战略，各地政府纷纷发布上云政策，各行各业掀起了上云热潮。 在数字经济时代，业务上云成为企业践行数字化转型的第一步。所谓“上云”，是指企业通过网络（专线或互联网），将系统和平台从原来的IDC迁移到云端，利用云厂商的计算、存储、网络等资源提供基础服务能力。根据上云策略的不同，可以选择IaaS、PaaS、SaaS等不同的资源。 当企业明确上云战略后，随即会面临两个根本问题： 业务上云到底能够为企业带来什么价值？ 企业又该如何上云？ 本文将围绕以上两个问题，通过一个真实项目的实践给大家提供参考。
大多数的敏捷团队是由10位以内不同角色的人员组建。其中包括但不仅限于BA、QA、UX、PM、DEV等关键角色。我们通过成熟的方法论以及每日站立会议（Stand-up Meeting）、迭代计划会议（Iteration Plan Meeting）、迭代启动会议（Iteration Kickoff Meeting，IKM）、开卡（Kickoff）、结卡（Desk Check，DC）和回顾会议（Retrospective）等各种逐渐“标准化”的敏捷活动，能够顺利地运行一个小规模的项目。 然而，当项目规模逐渐增大、项目成员人数逐渐增加时，为了有效协作，我们需要将整个大规模团队拆分为多个小规模的敏捷小组。但组与组之间的业务交互频繁，组内以及组间的各种沟通交流，会让原本快捷有效的敏捷活动变得繁琐。 尤其对于测试来说，小规模的项目中一般配有一到两名QA，负责所有功能模块的测试工作。但大规模的项目中，QA不仅要关注本组内的功能，同时还要考虑组与组间存在关联功能的测试。那么如何在高节奏的迭代中，进行大规模敏捷测试呢？
在当今的云原生世界中，管理权限和访问控制已经成为许多组织面临的重要挑战。随着应用程序和微服务变得更加分布式，必须确保只有合适的人和系统可以访问合适的资源。 然而，管理这种复杂性可能很困难，特别是随着团队和组织的增长。这就是为什么来自亚马逊网络服务（AWS）的新开源项目 Cedar 是身份和资源管理（IAM）领域的一次地震性变革，这表明应用程序权限问题已经变得太大而无法忽略。 传统上，组织依赖于访问控制列表（ACL）和基于角色的访问控制（RBAC）来管理权限。然而，随着资源和用户数量的增加，管理和扩展这些策略变得困难。这就是策略即代码出现的原因。它使开发人员能够编写像任何其他代码一样可以进行版本控制、测试和部署的代码策略。这种方法比传统方法更具可扩展性、灵活性和可审计性。
