话题公司 › slack

公司:slack

Slack是由Slack技术所开发的一款基于云端运算的即时通讯软件,现属赛富时所有。Slack这个词其实是一个缩写,意思是“所有可搜索的会话和知识日志”(Searchable Log of All Conversation and Knowledge)。

Balancing Old Tricks with New Feats: AI-Powered Conversion From Enzyme to React Testing Library at Slack

In the world of frontend development, one thing remains certain: change is the only constant. New frameworks emerge, and libraries can become obsolete without warning. Keeping up with the ever…

The Scary Thing About Automating Deploys

Most of Slack runs on a monolithic service simply called “The Webapp”. It’s big – hundreds of developers create hundreds of changes every week.

Deploying at this scale is a unique challenge. When people talk about continuous deployment, they’re often thinking about deploying to systems as soon as changes are ready. They talk about microservices and 2-pizza teams (~8 people). But what does continuous deployment mean when you’re looking at 150 changes on a normal day? That’s a lot of pizzas…

Building Custom Animations in the Workflow Builder

Slack's Workflow Builder has introduced improvements to its drag-and-drop feature. The development team implemented custom animations, including a tilt effect, to enhance the user experience during step dragging. They also created dynamic placeholders to indicate valid drop locations for steps. Spacing issues caused by hint boxes were solved by hiding them while dragging. The team utilized the onBeforeCapture responder to handle the state updates properly. Through these enhancements, Slack aims to provide a pleasant and productive experience for users, showcasing their dedication to craftsmanship.

The Query Strikes Again

数据存储团队通过实施限流机制和断路器模式,有效地保护数据库免受过多查询的影响。他们还采用了指数退避算法来适应失败的作业,并停止重试。此外,忘记用户作业通过优化查询和减少负载,对减轻主数据库压力发挥了重要作用。这些措施有助于确保Slack数据库基础设施的稳定性和可靠性,提供流畅的用户体验,并减轻类似事件的影响。

Executing Cron Scripts Reliably At Scale

Cron scripts are responsible for critical Slack functionality. They ensure reminders execute on time, email notifications are sent, and databases are cleaned up, among other things. Over the years, both the number of cron scripts and the amount of data these scripts process have increased. While generally these cron scripts executed as expected, over time the reliability of their execution has occasionally faltered, and maintaining and scaling their execution environment became increasingly burdensome. These issues lead us to design and build a better way to execute cron scripts reliably at scale.

Running cron scripts at Slack started in the way you might expect. There was one node with a copy of all the scripts to run and one crontab file with the schedules for all the scripts. The node was responsible for executing the scripts locally on their specified schedule. Over time, the number of scripts grew, and the amount of data each script processed also grew. For a while, we could keep moving to bigger nodes with more CPU and more RAM; that kept things running most of the time. But the setup still wasn’t that reliable — with one box running, any issues with provisioning, rotation, or configuration would bring the service to a halt, taking some key Slack functionality with it. After continuously adding more and more patches to the system, we decided it was time to build something new: a reliable and scalable cron execution service. This article will detail some key components and considerations of this new system.

Traffic 101: Packets Mostly Flow

Slack handles billions of inbound network requests per day, all of which traverse through our edge network and ingress load balancing tiers. In this blog post, we’ll talk about how a request flows — from a Slack’s user perspective — across the vast ether of the network to reach AWS and then Slack’s internal services.

Real-time Messaging

Did you know that ground stations transmit signals to satellites 22,236 miles above the equator in geostationary orbits, and that those signals are then beamed down to the entire North American subcontinent? Satellite radios today serve hundreds of channels across 9,540,000 square miles. Unless you’re working at a secret military facility, deep underground, you can enjoy satellite radio everywhere.

Just like the satellites, Slack sends millions of messages every day across millions of channels in real time all around the world. If we look at the traffic on a typical work day, it shows that most users are online between 9am and 5pm local time, with peaks at 11am and 2pm and a small dip in between for lunch hour. Though the working hours are similar across regions, looking at the two peaks in the graph below, it is evident that prime time is not the same: It’s post-noon in some regions and pre-noon in other regions. Each colored line in the below graph represents a region.

Tracing Notifications

Notifications are a key aspect of the Slack user experience. Users rely on timely notifications of mentions and DMs to keep on top of important information. Poor notification completeness erodes the trust of all Slack users.

Technology Lifecycle

This blog post discusses the strategies that Slack uses to manage the lifecycle (development, support, and eventual retirement) of infrastructure projects, through the lens of the migration through three successive internal “platform” offerings.

Hakana: Taking Hack Seriously

We started migrating to a different language called Hack in 2016. Hack was created by Facebook after they had struggled to scale their operations with PHP. It offered more type-safety than PHP, and it came with an interpreter (called HHVM) that could run PHP code faster than PHP’s own interpreter.

Mobile Developer Experience at Slack

The mobile developer experience team empowers developers to ship code with confidence while enjoying a pleasant and productive engineering experience.

BuildRock: A Build Platform at Slack

Our build platform is an essential piece of delivering code to production efficiently and safely at Slack. Over time it has undergone a lot of changes, and in 2021 the Build team started looking at the long-term vision.

Some questions the Build team wanted to answer were:

  • When should we invest in modernizing our build platform?
  • How do we deal with our build platform tech debt issues?
  • Can we move faster and safer while building and deploying code?
  • Can we invest in the same without impacting our existing production builds?
  • What do we do with existing build methodologies?

In this article we will explore how the Build team at Slack is investing in developing a build platform to solve some existing issues and to handle scale for future.

Slowing Down to Speed Up - Circuit Breakers for Slack's CI/CD

How Slack increased developer productivity and prevented cascading internal failures by implementing orchestration-level circuit breakers.

Automated Incident Management Through Slack

How Airbnb automates incident management in a world of complex, rapidly evolving ensemble of micro services.

投资人谈Slack:百亿美金公司养成记

Slack最初是一家游戏公司,面向的市场跟现在完全不一样,这家公司的团队在四个不同的城市,他们想要同步工作、分享状态,当他们意识到游戏开发业务进展不好之后,他们打算关停游戏,又在内部使用的通信消息服务中有一定的价值。所以他们重写了代码,将其命名为Slack去发布。

AutoTransform: Efficient Codebase Modification

How Slack is bringing automation to bear to solve the problem of maintaining, modifying, and upgrading codebases.

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.125.4. UTC+08:00, 2024-05-25 01:06
浙ICP备14020137号-1 $访客地图$