Слак не работает сегодня

Slack был недоступен несколько часов в первый рабочий день 2021 года

4 января 2021 года многие пользователи Slack столкнулись с невозможностью подключится к сервису обмена сообщениями из-за сбоя в работе платформы. Компания уведомила клиентов о серьезном инциденте и смогла восстановить большинство сервисов через несколько часов. Некоторое время продолжали наблюдаться другие проблемы со Slack — не работали календари Google и Outlook, также не отправлялись некоторые уведомления по электронной почте, например, уведомление о новом прямом сообщении в Slack. Эту проблему сервис обещал решить в ближайшее время.

Некоторое время были отключены почти все сервисы месседжера.

Представитель Slack не смог пояснить изданию New York Times, сколько пользователей из более чем 10 млн пострадали, и что вызвало этот сбой. Компания пообещала предоставить информацию после расследования.

Во время отключения Slack пользователи не могли отправлять сообщения, загружать каналы, совершать звонки или даже входить в сервис. У некоторых пользователей до сих пор наблюдаются проблемы с календарями и уведомлениями. Из-за сбоя мессенджера многие клиенты обратились либо к конкурентам Slack, таким как Google или видеосервисы Zoom, либо обратно к телефонным звонкам и электронной почте — инструментам, которые могли показаться устаревшими для некоторых сотрудников, которые, работая из дома большую часть прошлого года, привыкли к удобству и оперативности приложения Slack на ноутбуке или смартфоне.

Некоторые корпоративные пользователи сервиса в Twitter с оптимизмом рассказывали, как они пытаются работать без Slack в первый рабочий день 2021 года.

12 мая 2020 года у Slack произошел первый значительный сбой за долгое время, который специалисты компании устраняли почти сутки.

В начале декабря прошлого года поставщик облачных корпоративных решений Salesforce приобрел разработчика сервиса обмена сообщениями Slack Technologies за $27,7 млрд.

Источник

В работе Slack произошёл массовый сбой: пользователи не могут подключиться и отправить сообщения Статьи редакции

На сбои жалуются пользователи из России, США, Европы и Японии.

Днем 29 сентября в работе мессенджера Slack произошёл сбой. На сервисе Downdetector более 1000 жалоб на работу сервиса: 55% пользователей жалуются на сбой подключения, у 39% не отправляются сообщения. Сбои зафиксированы в России, США, Европе и Японии.

Представители компании извинились за неполадки. Slack исследует проблему.

Да всё в порядке уже. Новость опоздала на пару часов и перестала быть новостью))

Хотя твит slack is down im finally free — смешной. И печальный одновременно..

Вспомнился сейчас спор с @Vitold S. в комментариях, который произошел недавно под аналогичным постом, но про Telegram.

Для рабочих моментов должен быть корпоративный мессенджер если только вы не на леваке.
ред.

пусть на экосистему утопия перейдут. Поприятнее будет.

В автоматах продают не только игрушки для детей, но и работающие мини-технику, мебель и посуду. Зачем компании сертифицируют псевдоутварь и можно ли на ней заработать — в пересказе NYT.

И всех сотрудников старше 60 лет и страдающих хроническими заболеваниями.

Совсем скоро стартует AI Journey — международная конференция по искусственному интеллекту и анализу данных. Её проводит Сбер, и в этом году она пройдёт в онлайн-формате. Зарегистрироваться можно уже сейчас, а мы пока расскажем, почему мероприятие будет интересно всем: от учёных до школьников.

Сколько пользователей затронула проблема — неизвестно.

Электромобили будут стоит от 3,5 млн рублей.

История создания платформы Hashbon Rocket от начала запуска до покорения DeFi рынка

В некоторых регионах — с 23 октября.

На «Неделях российского бизнеса» прошел Форум по креативным индустриям и интеллектуальной собственности, где представители власти, бизнеса и институтов развития обсудили проблемы защиты интеллектуальной собственности в России, введения третейских судов и регулирования оборота продуктов, созданных искусственным интеллектом.

Источник

Самый ужасный день в компании Slack

Эта статья описывает технические детали проблем, из-за которых Slack упал 12 мая 2020 года. Больше о процессе реагирования на тот инцидент см. хронологию Райана Каткова «Обе руки на пульте».

12 мая 2020 года у Slack произошел первый значительный сбой за долгое время. Вскоре мы опубликовали краткое изложение инцидента, но это довольно интересная история, поэтому хотели бы подробнее остановиться на технических деталях.

Пользователи заметили даунтайм в 16:45 по тихоокеанскому времени, но на самом деле история началась около 8:30 утра. Команда разработки по надёжности БД (Database Reliability Engineering Team) получила предупреждение о значительном увеличении нагрузки на часть инфраструктуры. В то же время команда по трафику (Traffic Team) получила предупреждения, что мы не выполняем некоторые запросы API.

Повышенная нагрузка на БД была вызвана деплоем новой конфигурации, которая вызвала давнюю ошибку производительности. Изменение было быстро определено и откатано — это был флаг функции, выполнявшей постепенный деплой, так что проблему решили быстро. Инцидент немного повлиял на клиентов, но это продолжалось всего три минуты, и большинство пользователей всё ещё могли успешно отправлять сообщения в течение этого короткого утреннего глюка.

Одним из последствий инцидента стало значительное расширение нашего основного уровня веб-приложений. Наш генеральный директор Стюарт Баттерфилд писал о некотором влиянии карантина и самоизоляции на использование Slack. В результате пандемии мы запустили значительно больше инстансов на уровне веб-приложений, чем в далёком феврале этого года. Мы быстро масштабируемся, когда воркеры нагружаются, как это произошло здесь — но воркеры гораздо дольше ждали завершения некоторых запросов к БД, что вызвало более высокую загрузку. Во время инцидента мы увеличили количество инстансов на 75%, что привело к максимальному количеству хостов веб-приложений, которые мы когда-либо запускали до сегодняшнего дня.

Казалось, что всё прекрасно работает в течение следующих восьми часов — пока не выскочило предупреждение о необычно большом количестве ошибок HTTP 503. Мы запустили новый канал реагирования на инциденты, а дежурный инженер по веб-приложениям вручную увеличил парк веб-приложений в качестве первоначального смягчения последствий. Как ни странно, это нисколько не помогло. Мы очень быстро заметили, что часть инстансов веб-приложений находится под большой нагрузкой, в то время как остальные — нет. Начались многочисленные исследования, изучающие и производительность веб-приложений, и балансировку нагрузки. Через несколько минут мы определили проблему.

За балансировщиком нагрузки на 4-м уровне стоит набор инстансов HAProxy для распределения запросов на уровень веб-приложений. Мы используем Consul для обнаружения служб и consul-template для рендеринга списков здоровых бэкендов веб-приложений, к которым HAProxy должен направлять запросы.

Рис. 1. Высокоуровневое представление архитектуры балансировки нагрузки Slack

Однако мы не рендерим список хостов веб-приложений прямо из конфигурационного файла HAProxy, потому что обновление списка в таком случае требует перезагрузки HAProxy. Процесс перезагрузки HAProxy включает в себя создание совершенно нового процесса, сохраняя при этом старый, пока он не закончит работу с текущими запросами. Очень частые перезагрузки могут привести к слишком большому количеству запущенных процессов HAProxy и низкой производительности. Это ограничение находится в противоречии с целью автоматического масштабирования уровня веб-приложений, которая заключается в том, чтобы как можно быстрее вводить в эксплуатацию новые инстансы. Поэтому мы используем HAProxy Runtime API для управления состоянием сервера HAProxy без перезагрузки каждый раз, когда сервер веб-уровня входит в эксплуатацию или выходит из неё. Стоит отметить, что HAProxy может интегрироваться с DNS-интерфейсом Consul, но это добавляет лаг из-за TTL DNS, ограничивает возможность использования тегов Consul, а управление очень большими ответами DNS часто приводит к болезненным пограничным ситуациям и ошибкам.

Рис. 2. Как набор бэкендов веб-приложений управляется на одном сервере Slack HAProxy

В нашем состоянии HAProxy мы определяем шаблоны серверов HAProxy. Фактически, это «слоты», которые могут занимать бэкенды веб-приложений. Когда выкатывается инстанс нового веб-приложения или старый начинает отказывать, обновляется каталог сервисов Consul. Consul-template выводит новую версию списка хостов, а отдельная программа haproxy-server-state-management, разработанная в Slack, считывает этот список хостов и использует HAProxy Runtime API для обновления состояния HAProxy.

Мы запускаем M параллельных пулов инстансов HAProxy и веб-приложений, каждый пул в отдельной зоне доступности AWS. HAProxy сконфигурирован с N «слотами» для бэкендов веб-приложений в каждой зоне доступности (AZ), что даёт в общей сложности N*M бэкендов, которые могут быть направлены на все AZ. Несколько месяцев назад это количество было более чем достаточным — мы никогда не запускали ничего даже близко к такому количеству инстансов нашего уровня веб-приложений. Однако после утреннего инцидента с базой данных мы запустили чуть больше, чем N*M инстансов веб-приложений. Если представить слоты HAProxy как гигантскую игру в стулья, то некоторые из этих инстансов webapp остались без места. Это не было проблемой — у нас более чем достаточно возможностей для обслуживания.

Рис. 3. «Слоты» в процессе HAProxy с некоторыми избыточными экземплярами веб-приложений, которые не получают трафик

Однако в течение дня возникла проблема. Выявился баг в программе, которая синхронизировала список хостов, сгенерированный consul-template, с состоянием сервера HAProxy. Программа всегда пыталась найти слот для новых инстансов webapp, прежде чем освободить слоты, занятые старыми инстансами webapp, которые больше не работают. Эта программа начала выдавать ошибки и рано завершать работу, потому что не могла найти ни одного пустого слота, а это означало, что запущенные инстансы HAProxy не обновляли своё состояние. В течение дня группа автомасштабирования webapp увеличивалась и уменьшалась, а список бэкендов в состоянии HAProxy всё больше устаревал.

В 16:45 большинство инстансов HAProxy были способны отправлять запросы только к набору бэкендов, доступных утром, и этот набор старых бэкендов webapp теперь составлял меньшинство. Мы регулярно предоставляем новые инстансы HAProxy, так что оставалось несколько свежих с правильной конфигурацией, но большинство из них оказались старше восьми часов и поэтому застряли с полным и устаревшим состоянием бэкенда. В конечном итоге, произошёл сбой сервиса. Это случилось в конце рабочего дня в США, потому что именно тогда мы начинаем масштабировать уровень веб-приложений по мере снижения трафика. Автомасштабирование в первую очередь завершает работу старых инстансов webapp, и это означало, что в серверном состоянии HAProxy их осталось недостаточно для обслуживания спроса.

Рис. 4. Состояние HAProxy изменялось с течением времени и слоты начали ссылаться в основном на удалённые хосты

Как только мы узнали причину сбоя, он был быстро устранён с помощью плавного перезапуска флота HAProxy. После этого мы сразу задали вопрос: почему мониторинг не уловил эту проблему. У нас есть система оповещения для этой конкретной ситуации, но, к сожалению, она не сработала так, как предполагалось. Поломка мониторинга не была замечена отчасти потому, что система «просто работала» в течение длительного времени и не требовала никаких изменений. Более широкий деплой HAProxy, частью которого является это приложение, также относительно статичен. При низкой скорости изменений всё меньше инженеров взаимодействует с инфраструктурой мониторинга и оповещения.

Мы особо не переделывали этот стек HAProxy, потому что всю балансировку нагрузки постепенно переводим на Envoy (недавно мы перенесли на него трафик веб-сокетов). HAProxy хорошо и надёжно служил в течение многих лет, но у него есть некоторые операционные проблемы, как в этом инциденте. Сложный конвейер для управления состоянием сервера HAProxy мы заменим собственной интеграцией Envoy с плоскостью управления xDS для обнаружения конечных точек. Самые последние версии HAProxy (начиная с версии 2.0) тоже решают многие из этих операционных проблем. Тем не менее, мы уже некоторое время доверяем Envoy внутреннюю сервисную сетку, поэтому стремимся и балансировку нагрузки тоже перевести на него. Наше первоначальное тестирование Envoy + xDS в масштабе выглядит многообещающе, и в будущем эта миграция должна улучшить как производительность, так и доступность. Новая архитектура балансировки нагрузки и обнаружения служб не восприимчива к проблеме, вызвавшей этот сбой.

Мы стремимся поддерживать доступность и надёжность Slack, но в этом случае потерпели неудачу. Slack является важным инструментом для наших пользователей, и именно поэтому мы стремимся вынести урок из каждого инцидента, независимо от того, заметили его клиенты или нет. Приносим извинения за неудобства, вызванные этим сбоем. Обещаем использовать полученные знания для улучшения наших систем и процессов.

Источник

Slack не подключается к интернету? Мы получили правильное решение

Slack не подключается к интернету? Мы получили правильное решение

Проблемы со слабым соединением невозможно избежать, если у вас мучительно медленное или ненадежное интернет-соединение. Бывают случаи, когда Slack фактически не работает, и проблемы с подключением возникают на его серверах, но вам может не понравиться то, что вы собираетесь прочитать.

Основная причина проблем с подключением Slack не связана с их инфраструктурой, а скорее связана с подключением к Интернету.

Необходимость иметь дело с неотправленными сообщениями Slack или вызовами, когда звук часто включается и выключается, не является сценарием, частью которого вы хотите быть слишком долго. Вы не ожидаете получать это от этого популярного приложения для обмена сообщениями и совместной работы ежедневно, но сейчас не время терять терпение.

В этой статье мы рассмотрим некоторые из лучших способов решения проблем с подключением Slack.

Что я могу сделать, если Slack не подключается к Интернету?

1. Проверьте ваше интернет соединение

Это звучит довольно просто, но это первый шаг, чтобы проверить, относится ли проблема, с которой вы имеете дело, к приложению Slack или нет.

1. Откройте любую другую веб-страницу.
2. Если эта веб-страница не загружается, перезагрузите интернет-соединение.
3. Попробуйте загрузить Slack снова.

2. Запустите проверку слабого соединения

1. Войдите в свое рабочее пространство Slack.
2. Зайдите на https://my.slack.com/help/test для проверки соединений.
3. В разделе WebSockets см. Результаты как для WebSocket (Flannel [Primary]), так и для WebSocket (Flannel [Backup]) .
4. Успешный тест покажет значок проверенного круга .
5. Неудачный тест покажет значок предупреждения .
6. В случае каких-либо ошибок обратитесь к сетевому администратору или поставщику услуг Интернета

3. Очистите кеш

1. Откройте приложение Slack .
2. Нажмите Справка в строке меню вашего компьютера.
3. Выберите Устранение неполадок .
4. Нажмите Очистить кэш и перезагрузите .

4. Настройте прокси-сервер, чтобы соединение с Slack оставалось открытым.

Всегда помните, что прокси-серверы и брандмауэры часто связываются с соединением между серверами обмена сообщениями Slack и приложениями участников. Это может иметь место в случае сбоя WebSocket в нашем тесте Slack-соединения или если становится невозможным установить соединение из определенного места.

Попробуйте этот полезный совет, чтобы решить проблему:

1. Посетите https://my.slack.com/help/urls .
2. Здесь вы должны внести в белый список все указанные URL-адреса .
3. Посетите эту страницу из каждой рабочей области, если вашей среде требуется доступ к нескольким рабочим областям и / или организациям.
4. Затем убедитесь, что ваш прокси-сервер выполняет расшифровку SSL .
5. Если это так, пришло время освободить следующие домены: * .slack-msgs.com wss-primary.slack.com wss-backup.slack.com wss-mobile.slack.com .

5. Сбор и отправка сетевых журналов

Если ни одно из вышеперечисленных решений не оказалось полезным, соберите свои сетевые журналы и отправьте их в Slack. Шаги для настольного приложения подробно описаны здесь:

1. Еще раз откройте приложение Slack .
2. Нажмите Справка в строке меню вашего компьютера.
3. Выберите Устранение неполадок .
4. Выберите « Перезагрузить и собрать журналы сети» .
5. После перезапуска приложения воспроизведите проблему.
6. Выйдите и перезапустите Slack еще раз.
7. Пришло время отправить Slack электронное письмо по адресу feedback@slack.com с файлом Net Log или использовать контактную форму.

Примечание . Имя файла должно начинаться с net-log.

Вывод

Мы надеемся, что это руководство помогло вам исправить проблемы с подключением Slack, вызванные самим Интернетом, антивирусным программным обеспечением или настройками безопасности, сбоями со сторонними службами или ошибками с хранилищем приложений или серверами Slack.

Знаете ли вы какие-нибудь альтернативные решения? Просто отключите звук в комментариях ниже.

Источник