At Salesforce, Trust is our number-one value, and it has its own special meaning to each part of the company. In our Technology, Marketing, & Products (TMP) organization, a big part of Trust is providing highly reliable Salesforce experiences to our customers, which can be challenging because of the scale of the Salesforce infrastructure, its range of tech stacks, and the many products that those tech stacks support. Because of that challenge — and because TMP must gauge reliability at both that high level (across products) and from a zoomed-in view (for individual services supporting those products) — agreeing on what “highly reliable” means and how to measure it is absolutely critical. So just as Salesforce employees refer to standardized branding guidelines to speak the same product language, we also need standardized service ownership guidelines to ensure that we’re speaking the same reliability language. This blog post is about the Salesforce journey to framing reliability in terms of service-level indicators (SLIs) and objectives (SLOs), which are often used in the enterprise software business to represent the true customer experience in a clear, quantitative, and actionable way.

Salesforce成立后第2个10年（2010-2019）的故事。

Salesforce成立前10年（1999-2009）的故事。

在《创新者的窘境:大公司面对突破性技术时引发的失败》(The Innovator’s Dilemma：When New Technologies Cause Great Firm to Fail）一书里，克莱顿·克里斯坦森（Clayton M. Christensen）提出了经典的大公司失败模型：第一步：大公司的现有技术服务主流市场，有更好的性能，但只做极少的渐进改善。

We can control the way Spark partitions our data and us it to parallelize computations on our dataset.

At Salesforce, we operate thousands of services of various sizes: monolith and micro-services, both customer-facing and internal, across multiple substrates, i.e. first party and public cloud infrastructure. In our earlier blog “READS: Service Health Metrics,” we talked about the Service Level Objective (SLO) framework called READS that we developed at Salesforce to standardize SLO tracking for Salesforce services using a minimal set of indicators. Note that, at Salesforce, we consider SLO tracking for features as critical to our customers and our success as SLO tracking for the services that serve the features. So, from here on, when we use the word “service,” we mean both a service and feature. A natural question to ask in this context might be, how do we manage the SLO onboarding process for services at scale? How do we simplify the Developer Experience (DX) for service owners? What are some key takeaways from our approaches?

Salesforce的成功无法离开其底层平台Salesforce Platform的支持。而Salesforce Platform的核心是元数据驱动的多租户数据模型。Salesforce平台使用元数据来管理其内部使用的每一个逻辑数据库对象。

We mitigated complexity in our Salesforce Commerce APIs by introducing a correlation ID as the unique identifier of requests across systems.

Presenting Eflow, our ML flow management system. We share some of its fundamental principles that lend it unique scaling properties.

At Salesforce, we want to ensure all our experiences meet or exceed current WCAG (Web Content Accessibility Guidelines) standards. These accessibility guidelines, while comprehensive, can be overwhelming to absorb. They’re also open to interpretation. A group of engineers and designers across our accessibility and design systems teams partnered to evaluate the latest WCAG color contrast guidelines and streamline standards for our work. We wanted to fully integrate WCAG and hope our process can inspire your teams to do the same.

To leverage the scale and agility of the public cloud, we have built a new generation of infrastructure platform for Salesforce.

A framework prescribing the minimal set of indicators that every service needs to discern its health and performance.

By introducing a plug-in-like architecture, we could reshape how teams contribute native features to our mobile app.

There are three categories of monitoring design patterns that can help solve commonly occurring problems in software development.

We implemented a three-pronged strategy for the Salesforce Commerce APIs: monitoring, continous testing, and alerting.

We analyzed user email open and click behaviors across hundreds of billions of emails to build an algorithm for send time optimization.