Drupal támogatás: mit fedjen le egy szerződés

A legtöbben, akik Drupal támogatást keresnek, már a webhely tulajdonosai. Egy ügynökségtől örökölték, amely továbbállt, vagy egy fejlesztőtől, aki elment, és most egy frissítés késik, egy űrlap nem küld semmit, vagy megérkezett egy biztonsági közlemény, és senki nem tudja megmondani, vonatkozik-e rájuk. Nem értékesítési oldalra vágynak, hanem feladatleírásra: mi a munka, mit mond ki egy tisztességes szerződés, és mennyibe kerüljön.

Erről szól ez a cikk: milyen munkára van valóban szüksége havonta egy Drupal webhelynek, milyen üzemeltetési tények döntik el, hogy egy szerződés ér-e valamit, és milyenek a reális brit ársávok. Olvassa mellé egy szolgáltató ajánlatát, mert a hasznos rész az, amikor észreveszi, mely kérdésekre nem válaszol az ajánlat.

Két dolog különbözteti meg a Drupalt az általános webhely-karbantartástól. A biztonsági közlemények közzétett menetrend szerint jelennek meg, így a kitettségi ablak mérhető és szerződésbe írható. Egy Drupal webhely pedig független karbantartóktól származó közösségi modulok együttese, tehát valakinek mozgó frissítési célpontot kell követnie ön helyett.

Mit fedjen le egy Drupal támogatási szerződés? A pontosan az ön modulkészletére vonatkozó biztonsági közlemények figyelését, a mag és a közösségi modulok frissítéseinek meghatározott ciklusú, stagingen átvezetett telepítését, annak igazolását, hogy a mentések valóban visszaállíthatók, a rendelkezésre állás és az alkalmazáshibák figyelését, valamint megnevezett változtatási keretet a kis munkákra. Az Egyesült Királyságban ez nagyjából havi £250-tól, egy egyszerű bemutatkozó webhelyre, £2,000-ig vagy afölé terjed egy összetett webhelynél. Ez alatt figyelést vásárol, nem támogatást.

Mit jelent valójában a Drupal támogatás hónapról hónapra

Kérjen ajánlatot három ügynökségtől, és három csomagot kap Essential, Business és Enterprise néven, mindegyik főnevek felsorolása. A főnevek nem a munka. A munka visszatérő feladatok halmaza, amelyek vagy menetrend szerint történnek meg, vagy sehogy, és a hasznos gyakorlat az, ha a szolgáltatóval mindegyiket tevékenységként íratja le, felelőssel és gyakorisággal.

Nyolc ilyen van. A biztonsági közlemények figyelése és a javítások telepítése. A mag és a közösségi modulok frissítése. Függőségek és platformverziók emelése. Mentésellenőrzés és visszaállítási teszt. Rendelkezésre állás és alkalmazáshibák figyelése. Teljesítményregressziós ellenőrzés. Szerkesztői támogatás. És változtatási keret a mindig érkező apró munkákra.

Egy szerződés, amely mind a nyolcat megnevezi, nem lesz automatikusan jó, de az, amelyik négyet nevez meg, biztosan hiányos, és a kimaradó négy majdnem mindig ugyanaz: a visszaállítási teszt, a teljesítményregresszió, a platformfrissítés és a változtatási keret. Ezek a drágák, ezért tűnnek el.

Miért rejtik el a csomagnevek a munkát

A “korlátlan támogatási jegy” semmit nem mond arról, ki telepíti a hónap harmadik szerdáján a mag biztonsági javítását. A “proaktív felügyelet” semmit nem mond arról, hogy egy ember elolvassa-e a riasztást hajnali kettőkor, vagy hétfőig sorban áll. A “legjobb tudásunk szerint” semmit nem mond.

Cserélje ki minden fordulatot három tényre: a tevékenységre, annak gyakoriságára és a megnevezett szerepre, amely elvégzi. A legtöbb csomagoldal szétesik ettől a kezeléstől, és amelyik kibírja, az a szolgáltató, akivel érdemes beszélni.

A javítási ablak maga a termék

A Drupal menetrend szerint ad ki biztonsági kiadásokat, ami szokatlan és rendkívül hasznos. A mag biztonsági kiadásai a hónap harmadik szerdáján nyíló ablakban jelennek meg, 1200 America/New York időponttól, ami évszaktól függően 1600 vagy 1700 UTC. A közösségi projekteknek minden szerdán van biztonsági kiadási ablakuk , tehát a közösségi közlemények jóval sűrűbben érkeznek, mint a magra vonatkozók, és kötegekben.

Ebből az következik, hogy nem a sebezhetőség a kockázat. Mindenki, aki Drupalt futtat, ugyanabban a pillanatban kapja meg ugyanazt a sebezhetőséget, nyilvánosan közzétéve. A kockázat a közlemény megjelenése és a javítás éles rendszerbe kerülése közötti rés, mert ebben a résben a hiba dokumentált, indexelt, és olyanok keresik, akik gyorsabban olvasták el a közleményt, mint az ön szolgáltatója.

Egy támogatási szerződés minden más kikötése díszlet a résben eltelő órák számához képest. Az első kérdés egy leendő szolgáltatóhoz tehát számtan, nem filozófia. Jövő hónap harmadik szerdáján hány órakor olvassa el egy ember a közleményt, és mikorra kerül élesbe a javítás? A “szokásos SLA-nkon belül” erre nem válasz.

Hogyan pontozza a Drupal a kockázatot, és mit kezdjen ezzel a szerződése

Minden Drupal közlemény hordoz egy számot, és ez a szám a platform legkihasználatlanabb szerződésíró eszköze. A Drupal a NIST Common Misuse Scoring System, NISTIR 7864 szerint pontozza a sebezhetőségeket, 0 és 25 közötti pontszámot adva hat mérőszám alapján: hozzáférési bonyolultság, hitelesítés, bizalmasságra gyakorolt hatás, sértetlenségre gyakorolt hatás, kihasználó kód elérhetősége és a célpont elterjedtsége.

A pontszám öt közzétett címkére képződik le. A 0 és 4 közötti pontszám Not Critical, az 5 és 9 közötti Less Critical, a 10 és 14 közötti Moderately Critical, a 15 és 19 közötti Critical, a 20 és 25 közötti pedig Highly Critical. Ezek a sávok nyilvánosak, stabilak, és egyik fél sem értelmezheti át őket.

Ettől lennének egy támogatási SLA természetes gerince, és szinte senki nem használja őket. Ahelyett, hogy saját súlyossági meghatározásokat találna ki, amelyeken a szolgáltató később vitatkozhat, írja a válaszvállalást közvetlenül a Drupal pontszámhoz: a Highly Critical megnevezett órán belül javítva, munkaidőn kívül is, a Critical egy munkanapon belül, a Moderately Critical a következő ütemezett ciklusban, a többi kötegelve. Egyik fél sem nyithatja újra, mit jelentett a “sürgős”, mert azt már eldöntötte egy harmadik szereplő.

A Highly Critical más üzemeltetési esemény

A Highly Critical magkiadások ritkák, és a Drupal másként kezeli őket. A biztonsági csapat előre közzétesz egy nyilvános bejelentést , hogy a webhelytulajdonosok fedezetet szervezhessenek. A PSA-2026-05-18 pontosan ezt tette: 2026. május 18-án figyelmeztetett egy szerdára, május 20-ra ütemezett, kritikusan súlyos magkiadásra, amely minden támogatott ágat érintett.

Ez az előzetes értesítés az, ami köré a szerződését építeni kell, mert a vészhelyzetet időponttá alakítja. Az a szolgáltató, aki hétfőn tud a bejelentésről, és szerdára fenntart egy telepítési idősávot, támogatási szolgáltatást működtet. Az, aki csütörtökön értesül róla, levelezőlistát működtet.

Van egy enyhítő megoldás is, amit érdemes ismerni. A Drupal Steward a Drupal Association és a biztonsági csapat által üzemeltetett, fizetős, globálisan elosztott webalkalmazás-tűzfal, amely hálózati szintű virtuális javítást ad a mag kritikusan súlyos sebezhetőségeire, így a webhely védett marad, amíg a frissítést tesztelik. Az árakat amerikai dollárban teszik közzé, és a forgalommal skálázódnak: 20 dollár alatt havonta egy nagyjából 1 millió HTTP-kérést kiszolgáló webhelynél, 100 dollár alatt havonta 10 millió felett. Időt vásárol, nem immunitást, és egy jó szerződés kimondja, ki fizeti.

Mit nem fed le a biztonsági közleményekre vonatkozó szabályzat

Három kivétel a biztonsági közlemények folyamatáról és jogosultságairól szóló szabályzatban megváltoztatja, mit kell tennie egy szerződésnek, és a legtöbb támogatási szerződés mindháromról hallgat.

Közlemény csak stabil kiadásokhoz jelenik meg. Ha a webhelyén egy modul alfa, béta, kiadásjelölt vagy fejlesztői verzióban fut, arról soha nem jelenik meg közlemény, és a hírek hiánya semmit nem jelent. A lefedettség ráadásul projektenként önkéntes, nem automatikus, tehát egy le nem fedett közösségi modul ismert hibát hordozhat úgy, hogy nincs értesítési csatorna.

Aztán jön az, ami sokakat meglep: külső könyvtárakhoz nem adnak ki közleményt, még akkor sem, ha egy közösségi projekt megköveteli valamelyik telepítését. A függőségként behúzott JavaScript vagy PHP könyvtár az ön gondja, ön követi, és nem fog megjelenni a Drupal hírfolyamában.

A lefedettséget vissza is lehet vonni

A biztonsági lefedettség nem örökre szól. A PSA-2026-07-22 visszavonta a lefedettséget a QA Accounts modultól azzal az indokkal, hogy a kényelmet a biztonság elé helyezi, és csak internetről el nem érhető webhelyekre készült.

Ilyen alakú ez a kockázat. Egy évekkel ezelőtt, lefedettség mellett telepített modul csendben elveszítheti azt, és a webhelyén semmi nem változik, ami ezt jelezné. Nyilvántartást vezetni minden telepített projektről, aktuális lefedettségi állapotával és kiadási stabilitásával, valódi visszatérő munka, és írásban a szerződésben a helye.

A függőség- és platformfrissítés támogatási munka

A Drupal támogatási szerződésekből leggyakrabban kizárt tétel az, amely végül eldönti, hogy a webhely fennmarad-e. A Drupal platformkövetelményei mozognak, méghozzá olyan lépésekben, amelyekhez tárhelyváltás kell, nem egy composer update.

PHP oldalon a Drupal 10 legalább PHP 8.1-et igényel , míg a Drupal 11 a 11.1 óta minimumként PHP 8.3-at követel meg. A PHP 8.5 támogatása a Drupal 11.3-ban érkezett meg, a Drupal 12.0 pedig kizárólag a PHP 8.5-öt támogatja. Ez az utolsó részlet többet nyom, mint amennyinek látszik: az a webhely, amely ma kényelmesen elvan PHP 8.1-en, két kényszerű platformlépésre van a Drupal 12-től.

Az adatbázis-követelmények ugyanennyit mozdultak. A Drupal 11-nek MySQL 8.0 vagy újabb, MariaDB 10.6 vagy újabb, PostgreSQL 16 vagy újabb, illetve SQLite 3.45 vagy újabb kell. A Drupal 10 elfogadta a MySQL 5.7.8-at, a MariaDB 10.3.7-et és a PostgreSQL 12-t. Egy menedzselt tárhely, amely még MySQL 5.7-et szolgál ki, akadály a frissítési úton, nem részletkérdés, és a mi fut jól a Drupalon című jegyzetünk leírja, mire érdemes váltani.

A Drupal 10 életciklusának vége már most szerződéses probléma

A Drupal 10 életciklusa 2026. december 9-én ér véget , és a Drupal 12 ugyanezen a héten jelenik meg, 2026. december 7-től kezdődően. A 11.3.x és a 10.6.x ág biztonsági támogatása szintén ekkor zárul. 2026 szeptemberében a biztonsági kiadásokat kapó ágak a 11.4.x, a 11.3.x és a 10.6.x.

A naptárhoz mérve ez nagyjából három hónap. Bármely Drupal 10 webhely, amelynek 2026 szeptemberében nincs árazott frissítési terve, decemberben vagy sürgősségi felárat fizet, vagy támogatás nélkül fut, és a második lehetőségről valakinek tudatosan kellene döntenie, nem sodródással.

Egy szerződés, amely megéri a díját, addigra már négy dolgot előállított: aktuális frissítési állapotjelentést, az egyedi modulok és a sablon elavult kódjának átvizsgálását, minden közösségi modul készültségi ellenőrzését a Drupal 11-re és 12-re, valamint írásos becslést. Ha a szolgáltatója egyiket sem készítette el, éppen ez a megállapítás. A Drupal migráció költségeiről, lehetőségeiről és határidőiről szóló bontásunk bemutatja, mivel jár a munka, és ugyanez a tervezés ott van a webhelyfejlesztési megbízásainkban is.

A mentés semmit nem ér, amíg a visszaállítás nincs tesztelve

Szinte minden Drupal támogatási szerződés ígér mentést. Nagyon kevés ígér visszaállítást, és ez a különbség adja a tétel teljes értékét. Az NCSC a kis szervezeteknek szóló útmutatójában világosan fogalmaz: ha elkészítette a mentést , tudnia kell, hogyan állítja vissza, és ellenőriznie kell, hogy minden fontosat tartalmaz.

Egy Drupal visszaállításnak három mozgó alkatrésze van, és a részleges mentések a másodikon buknak el, unalmas rendszerességgel. Kell az adatbázis, a nyilvános és privát fájlkönyvtár, valamint a konfiguráció. Az a mentés, amely az adatbázist rögzíti, de a fájlkönyvtárat nem, ép tartalmú és képek nélküli webhelyet állít vissza, ami egy felügyeleti szkriptnek működő webhelynek látszik, az ügyfélnek viszont katasztrófának.

Kérjen dátumozott visszaállítási tesztet, eldobható környezetben végrehajtva, írásos feljegyzéssel arról, mennyi ideig tartott és mi hiányzott. A legtöbb webhelynél a negyedévente ésszerű gyakoriság. Ha egy szolgáltató még sosem csinált ilyet, nem ismeri a saját helyreállítási idejét, és ön sem.

Rendelkezésre állás és hibafigyelés, és mit mér valójában a rendelkezésre állás

Nagy a távolság aközött, hogy a kiszolgáló fut, és aközött, hogy a webhely működik, a Drupal pedig pont ebbe a résbe esik. Egy PHP végzetes hiba, egy kimerült memórialimit, egy sikertelen adatbázis-kapcsolat vagy egy elrontott gyorsítótár-újraépítés mind olyan oldalt hoz létre, amelyet egy naiv ellenőrzés sikernek olvas, vagy egy egyszerű 500-as hibát, amelyre senki nem figyel.

A kiszolgálón mért felügyelet azt mondja meg, hogy a gép válaszol. Az alkalmazáson mért felügyelet valódi oldalt kér le, követi az átirányításokat, és ellenőrzi, hogy a várt tartalom szerepel-e a válaszban. Ez két különböző termék két különböző áron, és az az ajánlat, amely “rendelkezésre állás figyelését” ír anélkül, hogy megmondaná, melyiket, a kettő közül az olcsóbbat írja le.

Alatta ott van a Drupal saját naplója. A friss naplóüzenetek jelentése és a PHP hibanapló az a hely, ahol egy hibázó cron, egy elavult függvény vagy egy minden kérésnél kivételt dobó modul jóval a látogatói panasz előtt megjelenik. Valakinek menetrend szerint olvasnia kell őket. A valamit is jelentő rendelkezésre állási SLA-król szóló írásunk bemutatja, hogyan fordulnak a százalékok megengedett percekre.

Hogyan olvassunk kritikusan egy Drupal támogatási SLA-t

A legtöbb támogatási SLA azért íródik, hogy aláírják, nem azért, hogy használják, és azért írják alá, mert gyorsan olvassák el. Három kikötés hordozza szinte a teljes súlyt, és gondos elolvasásuk tíz percet vesz igénybe.

A válaszidő nem megoldási idő

Az az SLA, amely két órás választ ígér, rendszerint azt ígéri, hogy valaki két órán belül visszaigazolja a jegyet. Nem ígéri, hogy bárki ránéz a webhelyére. Az a szolgáltató, aki komolyan gondolja, megoldási célt vállal, vagy legalább diagnózisra és kerülő megoldásra vállal célt, a javítás idejét külön megadva.

Ahol a munka őszintén nem szorítható időkeretbe, ott a tisztességes szerződés ezt kimondja, és helyette folyamatos ráfordítást vállal a megoldásig. Ez valódi vállalás. A “két órás válaszidő” önmagában egy e-mail elküldésére szóló vállalás.

A súlyossági meghatározások mindent eldöntenek

Minden SLA-ban van súlyossági táblázat, és a súlyosságot rendszerint a szolgáltató sorolja be. Ez a kiskapu. Ha az 1-es prioritás meghatározása “a webhely nem elérhető”, akkor az a fizetés, amely az ügyfelek harmadánál elbukik, 3-as prioritás lesz, és jövő héten nézik meg.

A meghatározásokat az üzleti hatás köré írja, ne a technikai állapot köré, és tegyen kidolgozott példákat a szerződésbe: elbukó fizetési lépés, elérhetetlen adminisztrátori belépés, elromlott kapcsolatfelvételi űrlap az ajánlatkérő oldalon. Aztán állapodjanak meg, ki sorolja be a súlyosságot, és hogyan vitatható egy besorolás.

A fedezeti idő nem a munkaidő

A “munkaidő” és a “fedezet” mást jelent, mégis gyakran felcserélik őket. A fedezet az az időszak, amikor ketyeg az óra, és valaki köteles cselekedni. Ha a fedezet munkanapokon 09:00 és 17:30 között van, akkor egy decemberi szerdán 1700 UTC-kor közzétett közleményt legjobb esetben másnap reggel vesznek elő.

Kifejezetten a Drupalnál vegye észre, hogy a mag biztonsági ablaka 1600 vagy 1700 UTC-kor nyílik. Az a brit szolgáltató, akinek a fedezete 17:30-kor véget ér, szerkezetileg a peremen áll, tehát a Highly Critical közlemények munkaidőn kívüli kezelését külön kell megnevezni és beárazni.

Mi számít incidensnek, és mi van kizárva

A kizárások szakasza az a hely, ahol a szerződés csendben olcsóbbá válik, mint amilyennek látszik. A szokásos kizárások külön-külön teljesen ésszerűek, együtt viszont ésszerűtlenek: harmadik fél tárhelyhibái, az ügyfél munkatársai által okozott gondok, a nem a szolgáltató által telepített modulok hibái, minden, ami fizetős sablonhoz kapcsolódik, és minden, amit a szolgáltató hibajavítás helyett változtatásnak minősít.

Az utolsó az éles perem. Ha egy hibajavításhoz konfigurációs módosítás kell, és a konfigurációs módosítás számlázható, akkor szinte minden hiba átsorolható a számlázható oszlopba. Kérdezze meg egyenesen, hogyan különbözteti meg a szolgáltató a hibát a változtatástól, és kérjen mindkettőre két példát a saját közelmúltbeli munkájából.

Nézze meg azt is, mi történik harmadik felekkel. Amikor a fizetési átjáró, a CRM-összekötő vagy a tárhely hibázik, a szolgáltató összehangolja a megoldást, vagy a jegy hatókörön kívüliként zárul? Az összehangolás valódi munka, és megéri megfizetni, de csak akkor, ha a szerződés kimondja, hogy megtörténik.

A három szerződésmodell, őszintén összevetve

Szinte minden Drupal támogatási megállapodás három alak egyike, és mindegyik ésszerű válasz egy másik helyzetre. A hiba az, ha az egyik alakot vásárolja meg, és a másik viselkedését várja tőle.

Fix óraszám havonta

Vásárol egy óracsomagot, mondjuk 8 vagy 16 órát, és a szolgáltató arra fordítja, amit kér. Átlátható, ajánlatok között könnyen összevethető, és illik egy olyan szervezethez, ahol apró változtatások egyenletesen csordogálnak, és van belül valaki, aki rangsorolni tud.

A gyengesége, hogy a karbantartás ugyanabból a keretből versenyez a fejlesztésekkel. Egy zsúfolt hónapban a biztonsági javítás csendben veszít a kampányoldallal szemben, mert aki az órákat költi, annak határideje van, a javítás pedig nem érződik annak. Ha ezt a modellt választja, a szerződésben magában különítse el az órák egy részét karbantartásra.

Korlátlan hibajavítás és árazott változtatások

A szolgáltató fix havidíjért elnyeli a karbantartást és a kis javításokat, minden pedig, ami egy megállapodott küszöb fölé megy, külön árajánlatot kap. Ezt a modellt tolja a legtöbb ügynökség, és egy stabil webhelynél, ideges tulajdonossal, valóban ez a jó válasz, mert változó kockázatot alakít fix költségvetési sorrá.

A gyengesége a határvonal. A “kis javítás” mindaddig meghatározatlan, amíg valakinek szüksége nem lesz rá, a küszöb pedig aszerint mozdul, hogyan alakul a hónap. Ragaszkodjon írásos meghatározáshoz, ideálisan időkerethez, például minden, ami 30 percnél rövidebb, és havi jelentéshez arról, mit nyelt el a díj.

Tiszta elszámolás ráfordítás szerint

Nincs szerződés, van napidíj, és akkor van munka, amikor kéri. Ez a tisztességes választás egy alacsony kockázatú webhelyhez, amelynek a tulajdonosa valóban követi a frissítéseket, és olyan szervezeteknek, amelyeknek van belső tudásuk, és alkalmi szakértői segítségre van szükségük, nem fedezetre.

A gyengesége, hogy soha semmi proaktív nem történik, mert senkit nem fizetnek azért, hogy odanézzen. A ráfordítás szerinti munka a sorban állásban is rossz: ugyanazokért a mérnökökért versenyez a szerződéses ügyfelekkel, tehát rossz napon a válasz hetekben mérhető, nem órákban.

Az ösztönzési probléma a méretlen támogatásban

A méretlen támogatásnak van egy szerkezeti hibája, amelyről a szakmában senki nem beszél szívesen. Ha a szolgáltató ugyanannyit kap függetlenül attól, hány órát fogyaszt egy webhely, akkor minden az ön webhelyére fordított óra csökkenti a fedezetét, és az üzletileg észszerű viselkedés az, ha a lehető legkevesebbet fordítja rá.

Ez rendszerint nem hanyagságként jelenik meg. Úgy jelenik meg, hogy a gyors javítást részesíti előnyben a helyes helyett, a tünet elnyomását az ok felkutatása helyett, és elhalasztja azt a modulfrissítést, amely egynapi regressziós tesztelést kívánna. Az olcsó csomagoknál a fordított irányban is látszik, ahol a díj csak akkor jön ki, ha a webhelyhez tényleg soha nem nyúlnak hozzá.

Az ellensúly a jelentési kötelezettség. Egy havi jelentés a felhasznált órákról, a telepített frissítésekről, az értékelt közleményekről és a lezárt jegyekről mindkét fél számára láthatóvá teszi a fogyasztást, és a veszteséges ügyfélből beszélgetést csinál a szolgáltatás lassú leépülése helyett. Minden szolgáltató, aki bízik a modelljében, belemegy. Aki ellenáll, elárulja, mire való valójában a modell.

Hogyan néz ki üzemeltetésileg a jó munka

Három technikai gyakorlat választja el azt a Drupal szolgáltatót, aki biztonságosan tudja vinni a webhelyét, attól, aki improvizál. Egyik sem egzotikus, és mindháromról könnyű kérdezni.

Composer, vagy semmi

A Drupal saját dokumentációja nyers a frissítési módszerek keverésével kapcsolatban, és figyelmeztet, hogy a webhelyek kritikus frissítési problémákba futhatnak , ha a Composer frissítéseit más megközelítésekkel vegyítik, és hogy amint a Composer kezel egy modult, a magot is kezelnie kell. Az a szolgáltató, aki még FTP-n tölt fel modulmappákat, előbb-utóbb töröl egy vendor könyvtárat, amelytől egy közösségi modul függött.

Kérdezze meg, hogy a composer.json és a composer.lock verziókövetésben van-e, és hogy a Composer az éles rendszeren fut-e, vagy a lefordított csomagot telepítik. Mindkét válasz lehet helyes. A válasz hiánya nem lehet az.

Olyan staging, amely megegyezik az élessel

Az a staging, amelyen más PHP-verzió, más adatbázis-verzió vagy más modulkészlet fut, semmi hasznosat nem tesztel. A staging értelme az, hogy egy biztonsági javítás ott bukjon el, ahol nem kerül pénzbe, ezt pedig csak akkor teljesíti, ha a két környezet azokon a tengelyeken egyezik, amelyek eltörnek.

Kérdezze meg, hogyan frissül a staging az élesből, milyen gyakran, és tartalmaz-e anonimizált másolatot a valódi tartalomból. Egy három tesztcsomópontos staging nem hozza elő azt a frissítést, amely elrontja a 40 000 sort átfogó nézetet.

A konfiguráció verziókövetésben

A Drupal alapértelmezés szerint az adatbázisban tartja a konfigurációt , és a konfigurációkezelő rendszer épp azért létezik, hogy fájlokba exportálja, amelyek véglegesíthetők, átnézhetők és másik környezetbe importálhatók. Az a csapat, amely használja, determinisztikusan reprodukálja a webhely beállításait. Az a csapat, amely nem használja, az éles adminfelületen kattintgat és reménykedik.

Ez a legtisztább jelzés egy szolgáltatói beszélgetésben. Kérdezze meg, hogyan jut el egy stagingen elvégzett módosítás az éles rendszerbe. Ha a válasz leírás, nem pedig szünet, a beszélgetés többi része általában rendben lesz.

Ha nem tudják leírni a telepítést, az maga a válasz

Nincs udvarias módja kimondani. Az a szolgáltató, aki nem tudja egy nyugodt perc alatt leírni, hogyan jut el a kód a fejlesztő gépéről az ön éles webhelyére, azt mondja, hogy a telepítéseket rögtönzik. A rögtönzött telepítés az oka annak, hogy a biztonsági javítások csúsznak: senki nem akarja szerda este lefuttatni a kockázatos kézi folyamatot.

Az átadási kikötés, amelyet senki nem olvas el

Egyszer szolgáltatót fog váltani, és az a kikötés, amely ezt a pillanatot szabályozza, akkor íródik, amikor mindenki barátságos, és akkor olvassák el, amikor már senki. Négy dolgot kell világosan kimondania.

Kié a kód, az egyedi modulokkal és a sablonmunkával együtt, és milyen licenc alatt. Hol van a tároló, és hogyan száll át a hozzáférés. Hogy az adatbázis, a fájlok és a konfiguráció teljes exportját megnevezett formátumban, megnevezett számú munkanapon belül átadják. És hogy a DNS-t, a tárhelyet és a harmadik felek szolgáltatásainak belépési adatait átadják, nem pedig visszatartják.

A hiba rendszerint nem rosszindulat. Hanem olyan szolgáltató, aki a saját fiókján üzemelteti a webhelyét, nála van a tároló egyetlen példánya, és hat hétig válaszol, mert ön már nem fizető ügyfél. Kérje el az átadási kikötést, mielőtt aláír, és a vonakodást tekintse információnak.

Drupal 7: életciklus vége, kiterjesztett támogatás és a köztük lévő rés

A Drupal 7 biztonsági támogatása 2025. január 5-én ért véget . A közösség abbahagyta a javítások készítését, és az a hatalmas közösségi modulökoszisztéma, amely a Drupal 7-et hasznossá tette, vele együtt vesztette el a karbantartását.

A Drupal Association Extended Security Support Provider Programot működtet, és a HeroDevs és a Tag1 Consulting a program tanúsított szállítói. Ennek a támogatásnak a megvásárlása jogos döntés egy olyan szervezettől, amely idén valóban nem tud migrálni, és érezhetően jobb a semminél.

Amit nem tesz meg: nem teszi a webhelyet a szó szokásos értelmében biztonságossá. Egy kereskedelmi szállító azokat a sebezhetőségeket javítja, amelyeket megtalál vagy amelyekről szólnak neki, saját menetrend szerint, arra a modulkészletre, amelynek lefedését vállalta. Nem állítja helyre a nyilvános közleményfolyamatot, nem fed le minden közösségi modult, amit ön történetesen telepített, és nem terjed ki azokra a külső könyvtárakra, amelyektől ezek a modulok függenek. A kiterjesztett támogatás egy nem támogatott platform ellenőrzött üzemeltetésének módja, és a támogatási szerződés nem szinonimája a biztonságnak.

Ha 2026 szeptemberében Drupal 7-en van, az őszinte tanács az, hogy a pénzt migrációra költse, ne bérleti díjra. A 2026-os Drupal webfejlesztési útmutatónk bemutatja a platformot mai állapotában, a közleményfolyamat mélyebb részletei pedig a Drupal biztonságáról, közleményeiről és valós kockázatáról szóló jegyzetünkben találhatók.

Szerkesztői támogatás és a változtatási keret

Két tétel szorul ki a támogatási szerződésekből, mert nehéz körülhatárolni őket, és éppen ez a kettő az, amit az ügyfelek észrevesznek.

A szerkesztői támogatás azt jelenti, hogy van valaki, aki hozzá tud adni egy tartalomtípust, meg tud javítani egy nézetet, amely már nem szűr helyesen, be tud tanítani egy szerkesztőt személycsere után, vagy ki tudja deríteni, miért vág le arcokat egy képstílus. Kevéssé látványos és nagyon gyakori, és az a szerződés, amelyből hiányzik, olyan ügyfelet nevel, aki abbahagyja a kérdezést, és elkezdi kikerülni a webhelyet.

A változtatási keret a másik fele. Minden webhelyen felgyűlik az apró munkák sora: egy mező egy űrlapon, egy átirányítás egy oldal elköltözése után, egy módosítás abban, ki kapja a megkereséseket. Ha erre a sorra havi keretet nevez meg órában, azzal akadályozza meg, hogy negyedévente vészprojektté váljon. Havi két-négy óra reális egy kis webhelynél, 8 vagy 16 egy forgalmasnál.

Mennyibe kerül a Drupal támogatás az Egyesült Királyságban

Az alábbi számok a 2026-os házi becsléseink, brit ügynökségi munkára építve, nem publikált felmérésre. Olyan szolgáltatót feltételeznek, aki a fent leírt nyolc tevékenységet elvégzi, nem pedig egy támogatási postafiókkal megtoldott felügyeleti előfizetést.

Prózában: egy kis bemutatkozó webhely nagyjából havi £250 és £600 között van, ami közleményfigyelést, havi javítási ciklust, mentésellenőrzést és egy-két óra változtatást vesz meg. Egy közepes, integrációkkal működő webhely körülbelül £700 és £1,800 között mozog, mert minden integráció olyan regressziós felületet ad hozzá, amelyet minden magfrissítés után újra kell tesztelni. Egy összetett vagy többnyelvű, egyedi modulokat futtató webhely £2,000 körül indul, és eléri a £6,000-t vagy annál is többet.

A csak figyelést nyújtó megállapodások, ahol a szolgáltató követi a közleményeket, és megmondja, mi vonatkozik önre, de nem telepít, ennél lejjebb, nagyjából havi £250 és £450 között helyezkednek el. Állítsa ezeket a sávokat a brit ügynökségi napidíjak, £600 és £900 mellé, és egy £1,500-os szerződés körülbelül két mérnöknapot vesz meg. A díjak részletei a Drupal fejlesztői díjakról, készségekről és kiválasztásról szóló jegyzetünkben, a tágabb költségvetési kép pedig a szoftverkarbantartás költségeiről szóló írásunkban található.

Mi mozdít egy webhelyet az egyik sávból a következőbe

Az ösztön az, hogy a támogatást forgalom alapján árazzuk, a forgalom viszont majdnem lényegtelen. Egy havi 200 000 látogatást kiszolgáló webhely húsz modullal és integráció nélkül olcsóbban tartható, mint egy kétezret kiszolgáló, amelyben van egy CRM-összekötő, egy fizetési átjáró és egy egyedi migráció.

Három dolog hajtja valójában a költséget. A modulok száma, mert minden közösségi modul figyelendő közleményfolyam és minden magfrissítésnél kompatibilitási kockázat. Az integrációk száma, mert mindegyik külső szerződés, amely megváltozhat ön alatt, és regressziós teszt, amelyet újra le kell futtatni. És a szerkesztői forgalom, mert egy aktív szerkesztőség egyenletes ütemben termel támogatási kérdéseket, jogosultsági módosításokat és tartalommodell-igazításokat.

Az egyedi kód mindhármon szorzóként hat. Egy 12 000 sornyi saját modulkódot tartalmazó webhelynél minden minor kiadásnál kell egy elavultság-vizsgálat és egy regressziós kör, ami egynapi munka, és amit egy tisztán közösségi modulokból álló webhely megúszik. Innen jön a felső sáv, és jellemzően ezt a munkát kérik a szoftverfejlesztési megbízásainktól, hogy elnyeljék.

Kérdések egy leendő szolgáltatóhoz

Hat kérdés, és a válaszok, amelyektől aggódnia kell.

Melyik Drupal és PHP verzión fut most a webhelyünk, és mi a frissítési út? Az a válasz, amelyhez utána kell nézniük, rendben van. Az, amelyik egy hét múlva érkezik, nincs. Hogyan tudják meg, hogy egy biztonsági közlemény ránk vonatkozik? A “figyeljük a drupal.org-ot” gyenge; a webhelyenkénti modulleltár a kívánt válasz.

Vezessen végig a telepítési folyamatukon. Az itteni habozás a legerősebb negatív jelzés az egész beszélgetésben. Mikor állították vissza utoljára ezt a webhelyet mentésből? A “napi mentéseket készítünk” nem válasz erre. Mi van kizárva a szerződésből, és hogyan döntik el, hogy valami hiba vagy változtatás? És végül: ha távozunk, mit kapunk és milyen gyorsan?

Mi történik, ha nincs szerződés

Ez inkább sorozat, mint figyelmeztetés, és nagyjából ugyanabban a tempóban zajlik minden támogatás nélküli Drupal webhelyen.

Az első néhány hónapban nem történik semmi, és éppen ez a baj, mert mindenkit megtanít arra, hogy nem is kell történnie semminek. Valahol a hatodik és a tizenkettedik hónap között a frissítési hátralék átlépi azt a pontot, ahonnan a frissítések már nem biztonságosak egyesével, mert egy modulhoz újabb mag kell, ahhoz újabb PHP, amit a tárhely nem kínál. Egyetlen javítás telepítése projektté vált.

Aztán a webhely teljesen kicsúszik a platformtámogatásból, és egy böngésző- vagy PHP-változás elront valami láthatót. A javítás most már egy olyan frissítéssel kezdődik, amelyre senki nem tervezett keretet, sürgősségi munkaként árazva, a webhely dokumentálatlan részeit pedig újraépítik, nem megjavítják. Ha közben adatvédelmi incidens történik, és személyes adatok érintettek, az ICO 72 órán belüli bejelentést vár attól, hogy tudomást szereztek róla, amennyiben az incidens valószínűleg kockázattal jár az emberek jogaira és szabadságaira, ez pedig olyan határidő, amelyet naplókkal és mentésekkel tart be, amelyek vagy megvannak, vagy nincsenek.

A helyreállítás számlája megbízhatóan a megelőző szerződés többszöröse, és a különbség nem a munkaóra. Hanem az, hogy a tervezett munka kedden történik, visszaállítási tervvel, a sürgősségi pedig vasárnap, anélkül.

A hatókör tisztázása aláírás előtt

Mindennek nem az a célja, hogy bizalmatlanná tegye a szolgáltatókkal szemben. Hanem hogy értelmet adjon két ajánlat összevetésének, mert jelenleg a legtöbb Drupal támogatási ajánlat felépítésénél fogva összemérhetetlen: más szavak, más kizárások, és nincs közös meghatározás arra, mi a havi munka.

Vegye a nyolc tevékenységet, a Drupal kockázati sávokat, a három szerződésmodellt és a hat kérdést, és állítsa oda ahhoz, ami az asztalán van. Ami ezt kibírja, az valódi ajánlat.

A Mecanik a webhelyfejlesztési és szoftverfejlesztési munkája részeként támogat Drupal webhelyeket, és az első megbízás rendszerint leltár, nem javítás, mert a hozzánk érkező webhelyek többsége nem tudja megmondani, mely moduljait fedi még a biztonsági közlemények folyama .

Gyakran ismételt kérdések

Mit tartalmazzon egy Drupal támogatási szerződés? Nyolc tevékenységet: a biztonsági közlemények figyelését a pontos modulkészlete ellenében, a mag és a közösségi modulok frissítését meghatározott ciklusban, a függőségek és a PHP platform emelését, a mentések ellenőrzését tesztelt visszaállításokkal, a rendelkezésre állás és az alkalmazáshibák figyelését, teljesítményregressziós ellenőrzést, szerkesztői támogatást és órában megnevezett változtatási keretet. Az a szerződés, amely csak négyet nevez meg, hiányos, és a rendszerint hiányzó négy a visszaállítási teszt, a teljesítményellenőrzés, a platformfrissítés és a változtatási keret.

Mennyibe kerül havonta a Drupal támogatás az Egyesült Királyságban? A 2026-os házi becslésünk szerint egy kis bemutatkozó webhely nagyjából havi £250 és £600 között van, egy közepes, egy-két integrációval működő webhely £700 és £1,800 között, egy összetett, többnyelvű, egyedi modulokat futtató webhely pedig £2,000 és £6,000 között. A csak figyelést nyújtó megállapodások £250 és £450 körül vannak. A brit ügynökségi napidíjakhoz, £600 és £900 mellé állítva egy £1,500-os szerződés körülbelül két mérnöknapot vesz meg.

Mikor ad ki a Drupal biztonsági javításokat? A Drupal mag biztonsági kiadásai a hónap harmadik szerdáján nyíló ablakban jelennek meg, 1200 America/New York időponttól, ami évszaktól függően 1600 vagy 1700 UTC. A közösségi projekteknek minden szerdán van biztonsági kiadási ablakuk. A kritikusan súlyos magkiadásokat nyilvános bejelentés előzi meg, hogy a webhelytulajdonosok előre fedezetet szervezhessenek.

A Drupal 7 kiterjesztett támogatása ugyanaz, mint a biztonság? Nem. A Drupal 7 biztonsági támogatása 2025. január 5-én ért véget, és a Drupal Association a HeroDevs és a Tag1 Consulting céget tanúsítja az Extended Security Support Provider Program keretében. Ezek a szállítók azt javítják, amit lefednek, saját menetrend szerint, egy megállapodott modulkészletre. Ez nem állítja helyre a nyilvános közleményfolyamatot, nem fed le minden telepített közösségi modult, és nem terjed ki a külső könyvtárakra.

Mikor ér véget a Drupal 10 életciklusa? A Drupal 10 életciklusa 2026. december 9-én ér véget, ugyanazon a héten, amelyen a Drupal 12 megjelenik, 2026. december 7-től kezdődően. A 11.3.x és a 10.6.x ág biztonsági támogatása ugyanekkor zárul. A Drupal 12 kizárólag a PHP 8.5-öt támogatja, tehát a régebbi PHP-verziókon futó webhelyeknek a frissítés előtt kell tárhelyet váltaniuk, nem utána.