Salesforce Heroku leállás: Mi történik a telepített alkalmazásokkal?

Egy Heroku leállás nem mindig jelenti azt, hogy minden telepített alkalmazás teljesen offline állapotban van. A hatás attól függ, hogy a platform melyik része hibásodik meg: útválasztás, dinamográfiai hálózatépítés, adatszolgáltatások, telepítési eszközök, DNS, naplózás vagy egy integráció, például a Heroku Connect. Az operátorok számára a leggyorsabb válaszlépés az érintett réteg azonosítása egy egészséges alkalmazás újraindítása vagy módosítása előtt.

A Heroku saját incidenstörténete mutatja, hogy miért fontos ez a megkülönböztetés. 2025. június 10-én a Heroku súlyos platformzavarról számolt be, amely számos ügyfél számára akár 24 órás leállást is okozott. A Heroku incidens utáni összefoglalója szerint egy nem szándékos operációsrendszer-frissítés újraindította a hálózati szolgáltatásokat az éles hosztokon, miközben egy útválasztási beállítási hiba megakadályozta a helyes hálózati útvonalak újbóli alkalmazását. Ugyanez az incidens a belső eszközöket és a Heroku Status webhelyet is érintette, bonyolítva a diagnózist és a kommunikációt. A Heroku kijelentette, hogy az incidens nem biztonsági esemény volt, és hogy nem vesztek el ügyféladatok. Lásd a hivatalos, június 10-i leállás-összefoglalót .

A közelmúltban, 2026. május 8-án a Heroku egy upstream szolgáltatót érintő szolgáltatáskimaradásról számolt be, amely az észak-amerikai régió ügyfeleinek egy részét érintette. A jelentett tünetek között szerepelt a szakaszos kapcsolat, a megnövekedett adatbázis-késés és a harmadik féltől származó bővítményeket érintő teljesítményromlás. A Heroku később közölte, hogy az érintett erőforrásokat új rendelkezésre állási zónába migrálta, és visszaállította a webes alkalmazásokat és adatbázisokat. Az incidens előzményei a Heroku hivatalos incidensoldalán érhetők el .

Gyors hatásmátrix: mi törhet el egy Heroku kiesés során?

1. Az alkalmazások futtatása akkor is sikertelen lehet, ha a kód nem változott

Minden Heroku alkalmazás felügyelt konténerekben, úgynevezett dyno-kban fut. A webes dyno-k HTTP forgalmat fogadnak, a dolgozó dyno-k jellemzően háttérfeladatokat dolgoznak fel, míg az egyszeri dyno-k adminisztratív feladatokat látnak el. A Heroku dyno dokumentációja kifejti, hogy a dyno-kezelő felelős ezeknek a konténereknek a működéséért.

Egy platformprobléma tehát elérhetetlenné tehet egy korábban hibátlan kiadást alkalmazástelepítés nélkül. Ha a gazdagép hálózata, a dyno manager vagy az alapul szolgáló infrastruktúra elérhetetlenné válik, az alkalmazás akkor is leállhat, ha a kódja és a konfigurációja változatlan.

A 2025. június 10-i leállás során Heroku egy hálózati hibát írt le, amely megszakította a dyno-k kimenő kapcsolatát az érintett hosztokon. Ez egy fontos működési tanulság: egy alkalmazásfüggőségi hibának tűnő hiba az alkalmazásréteg alatt is keletkezhet.

2. Az útválasztási hibák 503-as hibákat, időtúllépéseket vagy időszakos sikert okozhatnak.

A Heroku HTTP routerei fogadják a bejövő forgalmat, és továbbítják a kéréseket a webes dinamométereknek. A hivatalos útválasztási dokumentáció leírja ezt az utat a terheléselosztóktól az útválasztókon keresztül az alkalmazásdinamikai processzorokig.

Ha az útvonalnak csak egy része hibás, a felhasználók arról számolhatnak be, hogy az oldal „néha működik”. Egy kérés elérheti a működő dinamómérőt, míg egy másik sikertelen lesz. Ezért van az, hogy több, különböző helyekről származó ellenőrzés informatívabb, mint egyetlen böngészőfrissítés.

A Heroku hibakód-hivatkozása akkor hasznos, ha a naplók továbbra is elérhetők. A H99 és az R99 kifejezetten platformhibaként van dokumentálva. Más kódok jelezhetnek kérési időtúllépést, elutasított háttérkapcsolatokat, karanténba helyezett dinamokat vagy alkalmazásszintű problémákat, így egy H-kód önmagában nem hibáztatható automatikusan egy Heroku-szintű incidensért.

3. Adatszolgáltatás-kimaradás esetén az alkalmazás futhat, de funkcionálisan használhatatlanná válhat

Egy alkalmazás rendelkezhet egészséges webdinamikával, miközben az adatbázisa lassú vagy elérhetetlen. Az adatokat nem igénylő oldalak továbbra is betöltődhetnek, miközben a bejelentkezés, a fizetés, a keresés, az írás vagy az API-hívások sikertelenek. Ez részleges leállást okoz, amely a végfelhasználók számára inkonzisztensnek tűnhet.

A 2026. május 8-i incidens hasznos példa, mivel a Heroku szakaszos kapcsolatról és megnövekedett adatbázis-késésről számolt be az érintett ügyfeleknél. A Heroku azt is tanácsolta az érintett ügyfeleknek, hogy az incidens során enyhítésként fontolják meg az adatbázis-feladatátvételt.

A tervezett karbantartás rövidebb idejű megszakításokat is okozhat. A Heroku Postgres karbantartási dokumentációja szerint a karbantartás újraindíthatja a társított alkalmazást, és a felhasználók több perces hibákat vagy késéseket tapasztalhatnak. Ezért a tervezett karbantartást és a váratlan platformkiesést meg kell különböztetni, mielőtt eszkalálnánk.

4. A Heroku Connect hibái miatt a Salesforce adatai elavultak lehetnek anélkül, hogy a webalkalmazást le kellene állítani

A Heroku Connect szinkronizálja az adatokat egy Salesforce-szervezet és a Heroku Postgres között. A Heroku Connect dokumentációja szerint a szolgáltatás adatszinkronizációt biztosít, ahelyett, hogy maga a webes futtatókörnyezetként működne.

Ha a Connect megszakad, a telepített alkalmazás elérhető maradhat, miközben a szinkronizált Salesforce-adatok frissítése leáll. A meglévő Postgres-példányból történő olvasás továbbra is működhet, de a felhasználók elavult rekordokat vagy késleltetett írásokat láthatnak az alkalmazás leképezésétől és munkafolyamatától függően.

A Heroku karbantartási dokumentációja kimondja, hogy a Heroku Connect karbantartása során a szinkronizálás és a konfiguráció nem érhető el, míg a Postgresben lévő meglévő adatok továbbra is elérhetők maradnak; a sorban álló változtatások megmaradnak, és a szinkronizálás utána folytatódik. Ez a viselkedés a Heroku Connect karbantartási műveletekben van dokumentálva .

5. A telepítési problémák nem feltétlenül jelentik a termelés leállását

Az operátoroknak külön kell választaniuk a „nem telepíthető” és az „alkalmazás nem érhető el” elemeket. A Heroku a buildeket, a Git push-eket, a telepítési API-kat, az irányítópultot, a parancssori felületet és a kapcsolódó felügyeleti műveleteket külön kategorizálja a futásidejű és adatszolgáltatásoktól. Egy eszközhiba blokkolhatja az új kiadást, miközben a jelenleg futó kiadás továbbra is kiszolgálja a forgalmat.

Ez a különbségtétel látható volt a Heroku 2026. május 5-i incidensében, amikor egyes ügyfelek nem tudtak Review Apps-okat létrehozni, de a Heroku kifejezetten arról számolt be, hogy a futó alkalmazásokat ez nem érintette.

A Heroku kiadási fázisának dokumentációja azt is megjegyzi, hogy ha egy kiadási fázisú feladat meghiúsul, az új kiadás nem kerül telepítésre, és az aktuális kiadás változatlan marad. Incidens esetén kerülje a beragadt folyamatot az élő alkalmazás meghibásodásának bizonyítékaként való értelmezéseként.

6. A DNS-incidensek eltérően befolyásolhatják az újonnan létrehozott alkalmazásokat vagy domaineket a meglévőktől

A DNS egy másik eset, ahol a hatókör szűk lehet. 2025 szeptemberében a Heroku egy upstream DNS-problémáról számolt be, amely késleltette az új alkalmazások és domainek DNS-rekordjainak kiépítését. A hivatalos incidens megjegyezte, hogy az újonnan létrehozott hostnevek elérhetetlenek maradhatnak, amíg a szolgáltatói problémát nem oldják meg, miközben az incidens hatóköre kibővült, hogy magában foglaljon néhány DNS-hibát a meglévő EU-régiós alkalmazásokhoz.

Gyakorlati diagnózis érdekében tesztelje a meglévő Heroku hostname-et egy nemrég hozzáadott egyéni domaintől függetlenül. A DNS-feloldást is ellenőrizze az alkalmazás állapotától függetlenül.

Mit kell először ellenőrizni egy feltételezett Heroku-leállás esetén?

• Először a Salesforce Trustot ellenőrizd. A Heroku szerint a Salesforce Trust lett az elsődleges incidens- és karbantartási kommunikációs csatorna 2025. október 10-én, míg a régebbi Heroku Status webhelyet párhuzamos tartalékként tartották meg az átmenet során. Lásd a Heroku Status dokumentációját .
• Határozza meg az érintett kategóriát. Válassza szét az alkalmazásokat/futásidejű környezetet, az adatszolgáltatásokat és az eszközöket. Ez megakadályozza a szükségtelen alkalmazásmódosításokat egy platformincidens során.
• Többet tesztelj, mint a kezdőlap. Ellenőrizz statikus végpontot, adatbázis-függő végpontot, háttérfeladatokat és adott esetben Salesforce-szinkronizált munkafolyamatot.
• Hibakódok és időbélyegek áttekintése. A Heroku router/futásidejű hibáit összefüggésbe hozni a hivatalos incidens kezdési időpontjával.
• Ellenőrizd, hogy a központi telepítések csak blokkolva vannak-e. Ha éles környezetben működik, kerüld a központi telepítés kényszerítését instabil vezérlősík-incidens esetén.
• Őrizze meg a bizonyítékokat. Jegyezze fel a kéréshibákat, a naplókat, a metrikák, az adatbázis késleltetését, az incidensazonosítókat és a pontos UTC-ablakokat.

Újra kell indítani a dinamót áramszünet esetén?

Csak akkor, ha az incidenssel kapcsolatos útmutató vagy a saját bizonyítékaid alátámasztják. Az újraindítás segíthet, ha egy adott dinamométer elakad, de eltávolíthat egy egészséges folyamatot, vagy további forgalmi zavart okozhat egy platformszintű incidens során.

A 2025. június 10-i incidensre a Heroku közzétett egy konkrét kerülő megoldást a Private Space alkalmazásokhoz: az érintett ügyfelek egyenként leállíthatták az egyes dinamós mérőket, így azok kicserélődtek. A Heroku kifejezetten figyelmeztetett, hogy ez nem garantálja a teljes helyreállítást, amíg az upstream szolgáltatások zavartalanul működnek, és hogy a dinamós mérőket nem szabad egyszerre mind kicserélni. Az incidensre vonatkozó útmutató a hivatalos elhárítási cikkben szerepel .

Ne általánosítsa ezt az eljárást minden kiesésre. Ha az adatbázis, az útválasztási réteg, a DNS-szolgáltató vagy a Heroku Connect a tényleges szűk keresztmetszet, akkor a webdynos újraindítása semmit sem hozhat.

A helyreállítás nem fejeződik be, amikor a kezdőlap újra elérhetővé válik.

A platform elérhetőségének visszatérése után a downstream rendszerek még mindig behozhatják a lemaradásukat. A Heroku szerint a 2025. júniusi leállás után késedelmes állapot e-mailek érkeztek, a Heroku Connect szinkronizációnak be kellett zárkóznia, és a kiadási fázisban olyan elmaradás volt, amelynek feldolgozása órákig tartott.

Éles alkalmazás esetén ellenőrizze a helyreállítást a teljes függőségi láncban:

• A HTTP sikerességi aránya és a késleltetés normalizálódott.
• Minden várt webes és munkavégző dinamó kifogástalan állapotban van.
• Az adatbázis-olvasások és -írások normál késleltetéssel sikeresek.
• A várólisták és az ütemezett feladatok feldolgozás alatt állnak, nem pedig felhalmozódnak.
• A Heroku Connect leképezések szinkronizálva vannak, ha használatban vannak.
• A telepítések és a kiadási fázisban lévő feladatok normálisan működnek.
• A naplók és a metrikák rendellenes késés nélkül érkeznek.
• A harmadik féltől származó bővítmények és külső API-k helyreálltak.

A lényeg

Egy Salesforce Heroku kiesés több különböző szinten is hatással lehet a telepített alkalmazásokra. A futásidejű és útválasztási incidensek közvetlenül elérhetetlenné tehetik az alkalmazásokat; az adatincidensek futtatni hagyhatják a folyamatokat, de megszakíthatják az alapvető funkciókat; a Connect incidensek elavulttá tehetik a Salesforce által támogatott adatokat; az eszközincidensek pedig blokkolhatják a telepítéseket anélkül, hogy befolyásolnák az éles környezetben már futó verziót.

A legjobb operatív válasz tehát nem az, hogy „mindent újra kell indítani”. Először azonosítsa, hogy a hiba az alkalmazásokban/futásidejű környezetben, az adatokban, az eszközökben, a DNS-ben vagy egy integrációban van-e. Hasonlítsa össze saját mérőszámait a Salesforce Trusttal, őrizze meg a bizonyítékokat, kövesse az incidensre vonatkozó enyhítési útmutatót, és a helyreállítás után ellenőrizzen minden függőséget. Ez a megközelítés csökkenti annak kockázatát, hogy egy platformincidensből saját alkalmazásincidens váljon.