Прекъсване на Salesforce Heroku: Какво се случва с внедрените приложения?

Прекъсването на Heroku не винаги означава, че всяко внедрено приложение е напълно офлайн. Въздействието зависи от това коя част от платформата не работи: маршрутизация, dyno мрежа, услуги за данни, инструменти за внедряване, DNS, регистриране или интеграция като Heroku Connect. За операторите най-бързият начин за реакция е да идентифицират засегнатия слой, преди да рестартират или променят здравословно приложение.

Историята на инцидентите на Heroku показва защо това разграничение е важно. На 10 юни 2025 г. Heroku съобщи за сериозно прекъсване на работата на платформата, което създаде до 24 часа престой за много клиенти. В обобщението на Heroku след инцидента се казва, че неволна актуализация на операционната система е рестартирала мрежовите услуги на производствените хостове, докато грешка в настройката на маршрутизацията е попречила на повторното прилагане на правилните мрежови маршрути. Същият инцидент е засегнал и вътрешните инструменти и сайта Heroku Status, усложнявайки диагностиката и комуникацията. Heroku заяви, че инцидентът не е събитие, свързано със сигурността, и че не са загубени данни за клиентите. Вижте официалното обобщение на прекъсването от 10 юни .

Съвсем наскоро, на 8 май 2026 г., Heroku съобщи за прекъсване на услугата, включващо доставчик на услуги от горния пазар, което засегна подгрупа от клиенти в региона на Северна Америка. Съобщените симптоми включват прекъсваща свързаност, повишена латентност на базата данни и влошена производителност, включваща добавки на трети страни. По-късно Heroku заяви, че е мигрирала засегнатите ресурси към нова зона на достъпност и е възстановила уеб приложенията и базите данни. Историята на инцидентите е достъпна на официалната страница за инциденти на Heroku .

Матрица за бързо въздействие: какво може да се счупи по време на прекъсване на Heroku?

1. Изпълнението на приложения може да се провали, дори когато кодът ви не е променен

Всички приложения на Heroku работят в управлявани контейнери, наречени dynos. Уеб dynos получават HTTP трафик, работните dynos обикновено обработват фонови задачи, а еднократните dynos се справят с административни задачи. Документацията за dyno на Heroku обяснява, че мениджърът на dyno е отговорен за поддържането на тези контейнери в експлоатация.

Следователно, проблем с платформата може да направи преди това здравословна версия недостъпна без внедряване на приложение. Ако хост мрежата, мениджърът на дино или основната инфраструктура станат недостъпни, приложението може да се провали, дори ако кодът и конфигурацията му са непроменени.

По време на прекъсването на 10 юни 2025 г., Heroku описа мрежова повреда, която прекъсна изходящата свързаност за динамометрите на засегнатите хостове. Това е важен оперативен урок: грешка, която изглежда като повреда на зависимостта на приложението, може да възникне под приложния слой.

2. Неуспехите при маршрутизиране могат да доведат до грешки 503, прекъсвания на времето или периодичен успех.

HTTP рутерите на Heroku получават входящ трафик и пренасочват заявки към уеб динамометри. Официалната документация за маршрутизиране описва този път от балансьорите на натоварването през рутерите до динамометрите на приложенията.

Ако само част от този път е нарушена, потребителите могат да съобщят, че сайтът „понякога работи“. Една заявка може да достигне до работещ динамометричен уред, докато друга се провали. Ето защо множество проверки от различни места са по-информативни от еднократно обновяване на браузъра.

Справката за кодове за грешки на Heroku е полезна, когато все още има налични лог файлове. H99 и R99 са специално документирани като грешки на платформата. Други кодове могат да показват изтичане на времето за изчакване на заявката, отказани връзки към backend, поставени под карантина динамометри или проблеми на ниво приложение, така че H-кодът сам по себе си не трябва автоматично да се обвинява за инцидент в целия Heroku.

3. Прекъсване на услугата за данни може да остави приложението работещо, но функционално неизползваемо

Едно приложение може да има работещи уеб динамометри, докато базата данни е бавна или недостъпна. Страниците, които не изискват данни, все още могат да се зареждат, докато влизането, плащането, търсенето, записът или API извикванията се провалят. Това създава частичен прекъсване, което може да изглежда непоследователно за крайните потребители.

Инцидентът от 8 май 2026 г. е полезен пример, тъй като Heroku съобщи за прекъсваща свързаност и повишена латентност на базата данни за засегнатите клиенти. Heroku също така посъветва засегнатите клиенти да обмислят превключване на базата данни при срив като смекчаваща мярка по време на инцидента.

Планираната поддръжка може да създаде и по-кратки прекъсвания. Документацията за поддръжка на Postgres на Heroku гласи, че поддръжката може да рестартира свързаното приложение и че потребителите могат да виждат грешки или забавяния в продължение на няколко минути. Следователно, планираната поддръжка и неочакван прекъсване на платформата трябва да се разграничат преди ескалиране на проблема.

4. Неуспехите в Heroku Connect могат да доведат до застаряване на данните от Salesforce, без да се налага да се спира уеб приложението.

Heroku Connect синхронизира данни между организация на Salesforce и Heroku Postgres. Според документацията на Heroku Connect , услугата осигурява синхронизация на данни, вместо да действа като самата уеб среда.

Ако Connect е прекъснат, внедреното приложение може да остане достъпно, докато синхронизираните данни на Salesforce спрат да се актуализират. Четенето от съществуващото копие на Postgres може все още да работи, но потребителите могат да виждат застояли записи или забавени записи в зависимост от съпоставянето и работния процес на приложението.

Документацията за поддръжка на Heroku посочва, че по време на поддръжката на Heroku Connect, синхронизацията и конфигурацията не са достъпни, докато съществуващите данни в Postgres остават достъпни; промените в опашката се запазват и синхронизацията се възобновява след това. Това поведение е документирано в „ Операции по поддръжка на Heroku Connect“ .

5. Проблемите с внедряването не означават непременно, че производството е спаднало

Операторите трябва да разделят „не може да се внедри“ от „приложението не е налично“. Heroku категоризира компилациите, Git push-овете, API-тата за внедряване, таблото за управление, CLI и свързаните с него операции за управление отделно от услугите за изпълнение и данни. Инцидент с инструментариума може да блокира ново издание, докато текущо изпълняваното издание продължава да обслужва трафик.

Тази разлика беше видима при инцидента на Heroku от 5 май 2026 г., когато някои клиенти не можаха да създават приложения за преглед, но Heroku изрично съобщи, че работещите приложения не са засегнати.

Документацията за фазата на издаване на Heroku също така отбелязва, че ако задача от фазата на издаване се провали, новата версия не се внедрява и текущата версия остава незасегната. По време на инцидент избягвайте да интерпретирате заседнал конвейер като доказателство, че активното приложение е претърпяло неуспех.

6. Инцидентите с DNS могат да засегнат новосъздадените приложения или домейни по различен начин от съществуващите.

DNS е друг случай, в който обхватът може да бъде стеснен. През септември 2025 г. Heroku съобщи за проблем с DNS нагоре по веригата, който забави предоставянето на DNS записи за нови приложения и домейни. Официалният инцидент отбеляза, че новосъздадените имена на хостове може да останат недостъпни, докато проблемът с доставчика не бъде разрешен, докато обхватът на инцидента се разви, за да включи някои DNS грешки за съществуващи приложения от региона на ЕС.

За практическа диагноза, тествайте съществуващото име на хост на Heroku отделно от наскоро добавения персонализиран домейн. Също така проверете DNS резолюцията независимо от състоянието на приложението.

Какво трябва да проверите първо по време на предполагаем прекъсване на Heroku?

• Първо проверете Salesforce Trust. Heroku казва, че Salesforce Trust се е превърнал в основен комуникационен канал за инциденти и поддръжка на 10 октомври 2025 г., като по-старият сайт на Heroku Status е запазен като паралелно резервно копие по време на прехода. Вижте документацията на Heroku Status .
• Определете засегнатата категория. Разделете приложенията/средата за изпълнение, услугите за данни и инструментите. Това предотвратява ненужни промени в приложенията по време на инцидент с платформата.
• Тествайте повече от началната страница. Проверете статична крайна точка, крайна точка, зависима от базата данни, фонови задачи и синхронизиран от Salesforce работен процес, ако е приложимо.
• Прегледайте кодовете за грешки и времевите отметки. Съпоставете грешките на рутера/runtime на Heroku с официалното време на започване на инцидента.
• Проверете дали внедряванията са просто блокирани. Ако производственият процес е в добро състояние, избягвайте налагането на внедряване по време на инцидент с нестабилна контролна равнина.
• Запазете доказателствата. Записвайте неуспешни заявки, лог файлове, показатели, латентност на базата данни, идентификатори на инциденти и точния UTC прозорец.

Трябва ли да рестартирате динометърите по време на прекъсване на електрозахранването?

Само когато указанията за инцидента или вашите собствени доказателства го подкрепят. Рестартирането може да помогне, когато даден динамометричен стенд е заседнал, но може също така да премахне здравословен процес или да създаде допълнителен отлив по време на инцидент на цялата платформа.

За инцидента от 10 юни 2025 г. Heroku публикува специфично решение за приложенията Private Space: засегнатите клиенти можеха да спират отделни динометъри един по един, така че те да бъдат подменени. Heroku изрично предупреди, че това не гарантира пълно възстановяване, докато услугите нагоре по веригата остават нарушени, и че динометърите не трябва да бъдат подменяни едновременно. Това специфично за инцидента ръководство е запазено в официалната статия за отстраняване на проблеми .

Не обобщавайте тази процедура за всеки прекъсване. Ако базата данни, рутиращото ниво, DNS доставчикът или Heroku Connect са действителното пречка, рестартирането на уеб динамометрите може да не постигне нищо.

Възстановяването не е завършено, когато началната страница се появи отново за първи път.

След като наличността на платформата се възстанови, системите надолу по веригата все още могат да наваксат. Heroku заяви, че след прекъсването през юни 2025 г. са били доставяни забавени имейли за състоянието, синхронизацията на Heroku Connect е трябвало да навакса, а фазата на пускане на пазара е имала натрупани задачи, чието изчистване е отнемало часове.

За производствено приложение, валидирайте възстановяването по цялата верига на зависимости:

• Процентът на успеваемост и латентността на HTTP са се нормализирали.
• Всички очаквани уеб и работни динамометри са в изправност.
• Четенето и записването в базата данни се осъществяват успешно с нормална латентност.
• Опашките и планираните задачи се обработват, вместо да се натрупват.
• Съпоставянията на Heroku Connect се синхронизират, ако се използват.
• Разгръщанията и заданията във фазата на пускане на пазара работят нормално.
• Логовете и показателите пристигат без необичайно забавяне.
• Добавките на трети страни и външните API са възстановени.

Долен ред

Прекъсване на Salesforce Heroku може да повлияе на внедрените приложения на няколко различни слоя. Инцидентите по време на изпълнение и маршрутизация могат директно да направят приложенията недостъпни; инцидентите с данни могат да оставят процесите работещи, но да прекъснат основните функции; инцидентите с свързване могат да направят данните, поддържани от Salesforce, остарели; а инцидентите с инструменти могат да блокират внедряванията, без да засегнат вече съществуващата продукция.

Следователно най-добрият оперативен отговор не е „рестартиране на всичко“. Първо определете дали повредата е в Приложения/Среда за изпълнение, Данни, Инструменти, DNS или интеграция. Сравнете собствените си показатели със Salesforce Trust, запазете доказателства, следвайте специфичните за инцидента указания за смекчаване на последиците и проверете всяка зависимост след възстановяване. Този подход намалява риска от превръщане на инцидент на платформата в инцидент на приложението.