Suport Drupal: ce ar trebui să acopere un contract

Cei mai mulți dintre cei care caută suport Drupal dețin deja site-ul. L-au moștenit de la o agenție care a mers mai departe sau de la un dezvoltator care a plecat, iar acum o actualizare are întârziere, un formular nu mai trimite nimic ori a apărut un aviz de securitate și nimeni nu poate spune dacă îi privește. Ceea ce vor nu este o pagină de vânzare. Este un caiet de sarcini: care este munca, ce spune un contract corect și cât ar trebui să coste.

Despre asta este articolul: munca de care un site Drupal are cu adevărat nevoie în fiecare lună, faptele operaționale care decid dacă un contract valorează ceva și intervale de preț britanice realiste. Citiți-l cu oferta unui furnizor alături, pentru că partea utilă este să observați la care dintre aceste întrebări oferta nu răspunde.

Două lucruri deosebesc Drupal de mentenanța obișnuită a unui site. Avizele lui de securitate urmează un calendar publicat, deci fereastra voastră de expunere este măsurabilă și poate intra în contract. Iar un site Drupal este un ansamblu de module contribuite cu întreținători independenți, deci cineva trebuie să urmărească pentru voi o țintă de actualizare în mișcare.

Ce ar trebui să acopere un contract de suport Drupal? Monitorizarea avizelor de securitate care privesc exact setul vostru de module, aplicarea actualizărilor de nucleu și de module contribuite pe un ciclu definit, prin staging, dovada că backupurile chiar se restaurează, monitorizarea disponibilității și a erorilor de aplicație și un buget de modificări declarat pentru lucrările mici. În Marea Britanie asta pornește de la circa £250 pe lună pentru un site de prezentare simplu și ajunge la £2,000 sau mai mult pentru unul complex. Sub acest prag cumpărați monitorizare, nu suport.

Ce înseamnă cu adevărat suportul Drupal, lună de lună

Cereți ofertă de la trei agenții și veți primi trei pachete numite Essential, Business și Enterprise, fiecare o listă de substantive. Substantivele nu sunt munca. Munca este un set de sarcini recurente care fie se întâmplă după un calendar, fie nu se întâmplă deloc, iar exercițiul util este să puneți furnizorul să descrie fiecare sarcină ca activitate, cu un responsabil și o frecvență.

Sunt opt. Monitorizarea avizelor de securitate și aplicarea patch-urilor. Actualizări de nucleu și de module contribuite. Actualizări de dependențe și de versiuni de platformă. Verificarea backupurilor și testarea restaurării. Monitorizarea disponibilității și a erorilor de aplicație. Verificări ale regresiilor de performanță. Suport editorial. Și un buget de modificări pentru lucrările mici care apar mereu.

Un contract care le numește pe toate opt nu este automat bun, dar un contract care numește patru este limpede incomplet, iar cele patru care lipsesc sunt aproape mereu aceleași: testarea restaurării, regresiile de performanță, actualizările de platformă și bugetul de modificări. Sunt cele scumpe, de aceea dispar.

De ce numele pachetelor ascund munca

“Tichete de suport nelimitate” nu spune nimic despre cine aplică un patch de securitate al nucleului în a treia miercuri a lunii. “Monitorizare proactivă” nu spune nimic despre dacă un om citește alerta la două noaptea sau dacă ea așteaptă până luni. “În limita posibilului” nu spune absolut nimic.

Înlocuiți fiecare formulare cu trei fapte: activitatea, frecvența ei și rolul numit care o execută. Cele mai multe pagini de pachete se dizolvă sub acest tratament, iar cele care rezistă indică furnizorii cu care merită să vorbiți.

Fereastra de patch-uri este tot produsul

Drupal publică lansările de securitate după un calendar, ceea ce este neobișnuit și enorm de util. Lansările de securitate ale nucleului ies într-o fereastră în a treia miercuri a lunii , începând la 1200 America/New York, adică 1600 sau 1700 UTC, în funcție de sezon. Proiectele contribuite au o fereastră de securitate în fiecare miercuri , deci avizele pentru module contribuite sosesc mult mai des decât cele pentru nucleu, și în serii.

Consecința este că vulnerabilitatea nu este riscul. Toți cei care rulează Drupal primesc aceeași vulnerabilitate în același moment, publicată la vedere. Riscul este decalajul dintre publicarea avizului și ajungerea patch-ului pe site-ul vostru de producție, fiindcă în acel decalaj defectul este documentat, indexat și scanat de oameni care au citit avizul mai repede decât furnizorul vostru.

Orice altă clauză dintr-un contract de suport este decor pe lângă numărul de ore din acel decalaj. Prima întrebare pentru un posibil furnizor ține deci de aritmetică, nu de filozofie. În a treia miercuri a lunii viitoare, la ce oră va citi un om avizul și până când va fi patch-ul în producție? “În termenul SLA-ului nostru standard” nu este un răspuns.

Cum punctează Drupal riscul și ce ar trebui să facă asta contractului vostru

Fiecare aviz Drupal poartă un număr, iar acel număr este cel mai puțin folosit instrument de redactare a clauzelor din platformă. Drupal punctează vulnerabilitățile cu NIST Common Misuse Scoring System, NISTIR 7864 , obținând un punctaj de la 0 la 25 pe șase criterii: complexitatea accesului, autentificarea, impactul asupra confidențialității, impactul asupra integrității, disponibilitatea unui exploit și răspândirea țintei.

Punctajul se traduce în cinci etichete publicate. Un punctaj de la 0 la 4 este Not Critical, de la 5 la 9 este Less Critical, de la 10 la 14 este Moderately Critical, de la 15 la 19 este Critical, iar de la 20 la 25 este Highly Critical. Aceste intervale sunt publice, stabile și nu pot fi interpretate de niciuna dintre părți.

Ceea ce le-ar face coloana vertebrală firească a unui SLA de suport, și aproape nimeni nu le folosește. În loc să inventați definiții private ale gravității pe care un furnizor le poate contesta mai târziu, scrieți angajamentul de răspuns direct în raport cu punctajul Drupal: Highly Critical rezolvat într-un număr declarat de ore, inclusiv în afara programului, Critical într-o zi lucrătoare, Moderately Critical în următorul ciclu programat, restul grupat. Nicio parte nu mai poate rediscuta ce însemna “urgent”, pentru că a decis deja un terț.

Highly Critical este un eveniment operațional diferit

Lansările Highly Critical ale nucleului sunt rare, iar Drupal le tratează diferit. Echipa de securitate publică din timp un anunț de serviciu public , ca proprietarii de site-uri să își poată aranja acoperirea. PSA-2026-05-18 a făcut exact asta, avertizând pe 18 mai 2026 despre o lansare extrem de critică a nucleului programată pentru miercuri, 20 mai, care afecta toate ramurile susținute.

Acel preaviz este lucrul în jurul căruia ar trebui construit contractul vostru, pentru că transformă o urgență într-o programare. Un furnizor care știe de anunț luni și ține o fereastră de lansare pentru miercuri conduce un serviciu de suport. Un furnizor care află joi conduce o listă de e-mail.

Există și o măsură de atenuare care merită știută. Drupal Steward este un firewall de aplicații web contra cost, distribuit global, operat de Drupal Association și de echipa de securitate, care oferă patching virtual la nivel de rețea pentru vulnerabilitățile extrem de critice ale nucleului, astfel încât site-ul să fie protejat cât timp actualizarea este testată. Prețurile sunt publicate în dolari americani și cresc cu traficul: sub 20 de dolari pe lună pentru un site care servește aproximativ 1 milion de cereri HTTP, sub 100 de dolari pe lună peste 10 milioane. Cumpără timp, nu imunitate, iar un contract bun spune cine plătește.

Ce nu acoperă politica avizelor de securitate

Trei excluderi din politica privind procesul și permisiunile avizelor de securitate schimbă ce trebuie să facă un contract, iar cele mai multe contracte de suport tac în privința tuturor celor trei.

Avizele se emit doar pentru lansările stabile. Dacă un modul de pe site-ul vostru rulează într-o versiune alpha, beta, release candidate sau dev, nu va fi publicat niciodată un aviz pentru el, iar lipsa veștilor nu înseamnă nimic. Acoperirea este, în plus, opțională per proiect, nu automată, deci un modul contribuit neacoperit poate purta un defect cunoscut fără niciun canal de notificare.

Apoi vine cea care îi prinde pe oameni pe picior greșit: nu se emit avize pentru bibliotecile externe, nici atunci când un proiect contribuit vă obligă să instalați una. O bibliotecă JavaScript sau PHP adusă ca dependență este problema voastră, urmărită de voi, și nu va apărea în fluxul Drupal.

Acoperirea poate fi și retrasă

Acoperirea de securitate nu este permanentă. PSA-2026-07-22 a retras acoperirea modulului QA Accounts pe motiv că pune ușurința de folosire înaintea securității și este destinat doar site-urilor care nu sunt accesibile din internet.

Aceasta este forma riscului. Un modul instalat acum ani, pe atunci acoperit, poate pierde acoperirea în tăcere, iar pe site-ul vostru nu se schimbă nimic care să vă spună asta. Ținerea unui inventar al fiecărui proiect instalat, cu starea lui de acoperire și stabilitatea versiunii, este muncă recurentă reală și își are locul, în scris, în contract.

Actualizările de dependențe și de platformă sunt muncă de suport

Elementul cel mai des exclus dintr-un contract de suport Drupal este cel care decide, în cele din urmă, dacă site-ul supraviețuiește. Cerințele de platformă ale Drupal se mișcă, iar mișcarea se face în trepte care cer o schimbare de găzduire, nu un composer update.

La PHP, Drupal 10 cere cel puțin PHP 8.1 , în timp ce Drupal 11 impune PHP 8.3 ca minim începând cu 11.1. Suportul pentru PHP 8.5 a apărut în Drupal 11.3, iar Drupal 12.0 suportă exclusiv PHP 8.5. Ultimul detaliu cântărește mai mult decât pare: un site care stă azi comod pe PHP 8.1 se află la două mutări forțate de platformă distanță de Drupal 12.

Cerințele de bază de date s-au mișcat la fel de mult. Drupal 11 are nevoie de MySQL 8.0 sau mai nou, MariaDB 10.6 sau mai nou, PostgreSQL 16 sau mai nou ori SQLite 3.45 sau mai nou. Drupal 10 accepta MySQL 5.7.8, MariaDB 10.3.7 și PostgreSQL 12. O găzduire administrată care servește încă MySQL 5.7 este un blocaj pe drumul actualizării, nu un detaliu, iar nota noastră despre ce rulează Drupal cu adevărat bine arată încotro trebuie mutat.

Sfârșitul vieții Drupal 10 este deja o problemă de contract

Drupal 10 ajunge la sfârșitul vieții pe 9 decembrie 2026 , iar Drupal 12 apare în aceeași săptămână, începând cu 7 decembrie 2026. Suportul de securitate pentru ramurile 11.3.x și 10.6.x se încheie tot atunci. În septembrie 2026, ramurile care primesc lansări de securitate sunt 11.4.x, 11.3.x și 10.6.x.

Citit în raport cu calendarul, asta înseamnă aproximativ trei luni. Orice site pe Drupal 10 fără un plan de actualizare bugetat în septembrie 2026 va petrece decembrie fie plătind un tarif de urgență, fie rulând fără suport, iar a doua variantă ar trebui să fie o decizie asumată, nu una luată din inerție.

Un contract care își merită banii ar fi trebuit deja să producă patru lucruri: un raport privind starea actualizării, o scanare a codului depreciat din modulele proprii și din temă, o verificare a compatibilității fiecărui modul contribuit cu Drupal 11 și 12 și o estimare scrisă. Dacă furnizorul vostru nu a produs niciunul, tocmai asta este concluzia. Analiza noastră despre costurile, opțiunile și termenele migrării Drupal arată ce presupune munca, iar aceeași planificare stă în proiectele noastre de dezvoltare de site-uri web .

Backupurile nu valorează nimic până când o restaurare nu este testată

Aproape orice contract de suport Drupal promite backupuri. Foarte puține promit o restaurare, iar distincția este toată valoarea acelei linii. NCSC o spune limpede în ghidul său pentru organizații mici: odată ce ați făcut backupul , trebuie să știți cum să îl restaurați și să verificați că el conține tot ce contează.

O restaurare Drupal are trei piese în mișcare, iar backupurile parțiale cad la a doua cu o regularitate plictisitoare. Vă trebuie baza de date, directoarele de fișiere publice și private și configurația. Un backup care prinde baza de date, dar nu și directorul de fișiere, restaurează un site cu conținutul intact și fără imagini, ceea ce pentru un script de monitorizare arată ca un site funcțional, iar pentru un client ca un dezastru.

Cereți un test de restaurare datat, făcut într-un mediu de unică folosință, cu o notă scrisă despre cât a durat și ce lipsea. O dată pe trimestru este o frecvență rezonabilă pentru majoritatea site-urilor. Dacă un furnizor nu a făcut niciodată unul, nu își cunoaște propriul timp de revenire, și nici voi.

Monitorizarea disponibilității și a erorilor, și ce măsoară de fapt disponibilitatea

Există o distanță mare între un server care răspunde și un site care funcționează, iar Drupal stă chiar în mijlocul ei. O eroare fatală PHP, o limită de memorie epuizată, o conexiune eșuată la baza de date sau o reconstrucție stricată a cache-ului produc toate o pagină pe care o verificare naivă o citește ca succes, ori un simplu 500 pe care nimeni nu îl urmărește.

Monitorizarea măsurată la nivel de server vă spune că mașina răspunde. Monitorizarea măsurată la nivel de aplicație cere o pagină reală, urmează redirecționările și verifică prezența conținutului așteptat în răspuns. Sunt produse diferite cu prețuri diferite, iar o ofertă care spune “monitorizare a disponibilității” fără să spună care descrie varianta mai ieftină.

Dedesubt stă jurnalul propriu al Drupal. Raportul cu mesajele recente și jurnalul de erori PHP sunt locul unde un cron care eșuează, o funcție depreciată sau un modul care aruncă excepții la fiecare cerere vor apărea cu mult înainte ca un vizitator să se plângă. Cineva trebuie să le citească după un program. Materialul nostru despre SLA-urile de disponibilitate care înseamnă ceva explică felul în care procentele se traduc în minute permise.

Cum se citește critic un SLA de suport Drupal

Cele mai multe SLA-uri de suport sunt scrise ca să fie semnate, nu ca să fie folosite, și sunt semnate pentru că sunt citite repede. Trei clauze duc aproape toată greutatea, iar citirea lor atentă ia zece minute.

Timpul de răspuns nu este timpul de rezolvare

Un SLA care promite răspuns în două ore promite de obicei că cineva va confirma tichetul în două ore. Nu promite că se uită cineva la site-ul vostru. Furnizorii serioși se angajează la o țintă de rezolvare sau, cel puțin, la o țintă de diagnostic și soluție de ocolire, cu timpul de reparare menționat separat.

Acolo unde munca chiar nu poate fi încadrată în timp, un contract onest o spune și se angajează în schimb la efort continuu până la rezolvare. Acesta este un angajament real. “Răspuns în două ore”, de unul singur, este angajamentul de a trimite un e-mail.

Definițiile gravității decid totul

Orice SLA are un tabel al gravității, iar de obicei furnizorul atribuie gravitatea. Aceasta este portița. Dacă definiția Priorității 1 este “site indisponibil”, atunci o plată care eșuează pentru o treime dintre clienți este Prioritatea 3 și va fi privită săptămâna viitoare.

Scrieți definițiile în jurul impactului asupra afacerii, nu al stării tehnice, și includeți exemple concrete în contract: un pas de plată care eșuează, o autentificare de administrator imposibilă, un formular de contact stricat pe pagina de cerere. Apoi stabiliți cine atribuie gravitatea și cum contestați o încadrare.

Orele de acoperire nu sunt programul de lucru

“Program de lucru” și “acoperire” înseamnă lucruri diferite și sunt folosite adesea unul în locul celuilalt. Acoperirea este perioada în care ceasul merge și cineva este obligat să acționeze. Dacă acoperirea este de la 09:00 la 17:30 în zilele lucrătoare, un aviz publicat la 1700 UTC într-o miercuri din decembrie este preluat cel devreme a doua zi dimineață.

Pentru Drupal, în particular, observați că fereastra de securitate a nucleului se deschide la 1600 sau 1700 UTC. Un furnizor britanic a cărui acoperire se termină la 17:30 stă structural pe margine, deci aranjamentele din afara programului pentru avizele Highly Critical trebuie numite separat și puse la preț.

Ce se consideră incident și ce este exclus

Secțiunea excluderilor este locul unde un contract devine, pe tăcute, mai ieftin decât pare. Excluderile obișnuite sunt perfect rezonabile luate separat și nerezonabile luate împreună: defecțiuni ale găzduirii terțe, probleme provocate de personalul clientului, defecte în module neinstalate de furnizor, orice ține de o temă cumpărată și orice clasifică furnizorul drept modificare, nu defecțiune.

Ultima este muchia tăioasă. Dacă o reparație cere o schimbare de configurație, iar schimbările de configurație se facturează, atunci aproape orice defecțiune poate fi mutată în coloana facturabilă. Întrebați direct cum deosebește furnizorul o defecțiune de o modificare și cereți câte două exemple din munca lui recentă.

Verificați și ce se întâmplă cu terții. Când vinovat este procesatorul de plăți, conectorul CRM sau găzduirea, furnizorul coordonează rezolvarea ori tichetul se închide ca fiind în afara ariei? Coordonarea este muncă adevărată și merită plătită, dar numai dacă în contract scrie că se întâmplă.

Cele trei modele de contract, comparate cinstit

Aproape orice înțelegere de suport Drupal are una dintre trei forme, iar fiecare este un răspuns rezonabil la o situație diferită. Greșeala este să cumperi o formă așteptând comportamentul alteia.

Ore fixe pe lună

Cumpărați un pachet de ore, să zicem 8 sau 16, iar furnizorul le aplică la ce cereți. Este transparent, se compară ușor între oferte și se potrivește unei organizații cu un flux constant de mici modificări și cu cineva intern capabil să le prioritizeze.

Slăbiciunea lui este că mentenanța concurează cu funcționalitățile pentru același fond. Într-o lună aglomerată, aplicarea patch-urilor de securitate pierde tăcut în fața paginii de campanie, fiindcă persoana care consumă orele are un termen, iar patch-ul nu pare unul. Dacă alegeți acest model, rezervați o parte din ore pentru mentenanță chiar în contract.

Reparații nelimitate plus modificări ofertate

Furnizorul preia mentenanța și reparațiile mici pentru o sumă lunară fixă, iar tot ce depășește un prag convenit se ofertează separat. Este modelul pe care îl împing cele mai multe agenții, iar pentru un site stabil cu un proprietar neliniștit chiar este răspunsul potrivit, pentru că transformă un risc variabil într-o linie fixă de buget.

Slăbiciunea lui este granița. “Reparație mică” rămâne nedefinită până când are cineva nevoie de una, iar pragul se mută în funcție de cum merge luna. Cereți o definiție scrisă, ideal o limită de timp precum orice durează sub 30 de minute, și un raport lunar care arată ce a fost preluat.

Pur regie

Fără contract lunar, un tarif pe zi și muncă atunci când cereți. Este alegerea onestă pentru un site cu risc scăzut al cărui proprietar chiar va urmări actualizările și pentru organizațiile cu competențe interne care au nevoie de ajutor specializat ocazional, nu de acoperire.

Slăbiciunea lui este că nu se întâmplă niciodată nimic proactiv, fiindcă nimeni nu este plătit să se uite. Regia stă și prost la coadă: concurați cu clienții pe contract pentru aceiași ingineri, deci într-o zi proastă răspunsul se măsoară în săptămâni, nu în ore.

Problema de stimulente din suportul nelimitat

Suportul nelimitat are o problemă structurală despre care nimeni din domeniu nu discută cu plăcere. Dacă furnizorul este plătit la fel indiferent de câte ore consumă un site, atunci fiecare oră petrecută pe site-ul vostru îi reduce marja, iar comportamentul rațional comercial este să consume cât mai puține.

De obicei asta nu apare ca neglijență. Apare ca preferință pentru reparația rapidă în locul celei corecte, pentru înăbușirea unui simptom în locul urmăririi cauzei și pentru amânarea actualizării de modul care ar cere o zi de testare a regresiilor. Apare și în direcția opusă la planurile ieftine, unde tariful iese doar dacă site-ul chiar nu este atins niciodată.

Contragreutatea este o obligație de raportare. Un raport lunar cu orele consumate, actualizările aplicate, avizele evaluate și tichetele închise face consumul vizibil pentru ambele părți și transformă un cont nerentabil într-o discuție, nu într-o degradare lentă a serviciului. Orice furnizor încrezător în model va accepta. Un furnizor care se opune vă spune la ce servește de fapt modelul.

Cum arată munca bună la nivel operațional

Trei practici tehnice despart un furnizor Drupal capabil să vă țină site-ul în siguranță de unul care improvizează. Niciuna nu este exotică și despre toate trei se poate întreba ușor.

Composer, sau nimic

Documentația proprie a Drupal este fără menajamente în privința amestecării metodelor de actualizare și avertizează că site-urile pot întâmpina probleme critice de actualizare dacă actualizările prin Composer sunt combinate cu alte abordări și că, odată ce Composer gestionează un modul, trebuie să gestioneze și nucleul. Un furnizor care încă încarcă foldere de module prin FTP va șterge, la un moment dat, un director vendor de care depindea un modul contribuit.

Întrebați dacă composer.json și composer.lock sunt în controlul versiunilor și dacă Composer rulează în producție ori se livrează artefactul construit. Oricare răspuns poate fi corect. Lipsa unui răspuns nu poate.

Un mediu de staging care seamănă cu producția

Un staging cu altă versiune de PHP, altă versiune de bază de date sau alt set de module nu testează nimic util. Rostul stagingului este să lase un patch de securitate să cadă acolo unde nu costă bani, iar asta se întâmplă doar dacă cele două medii coincid pe axele care se rup.

Întrebați cum este împrospătat stagingul din producție, cât de des și dacă ține o copie anonimizată a conținutului real. Un staging cu trei noduri de test nu va scoate la iveală actualizarea care strică un view peste 40.000 de rânduri.

Configurația în controlul versiunilor

Drupal ține implicit configurația în baza de date , iar sistemul de gestiune a configurației există tocmai ca să o exporte în fișiere care pot fi comise, revizuite și importate în alt mediu. O echipă care îl folosește poate reproduce setările site-ului determinist. O echipă care nu îl folosește dă clic prin ecranele de administrare în producție și speră.

Acesta este cel mai clar semnal dintr-o discuție cu un furnizor. Întrebați cum ajunge în producție o schimbare făcută pe staging. Dacă răspunsul este o descriere, nu o pauză, restul discuției merge de obicei bine.

Dacă nu pot descrie lansarea, acesta este răspunsul

Nu există un fel politicos de a spune asta. Un furnizor care nu poate descrie, într-un minut fără grabă, cum ajunge codul de pe calculatorul unui dezvoltator pe site-ul vostru viu vă spune că lansările sunt improvizate. Lansările improvizate sunt motivul pentru care patch-urile de securitate întârzie: nimeni nu vrea să ruleze procedura manuală riscantă într-o seară de miercuri.

Clauza de ieșire pe care nu o citește nimeni

La un moment dat veți schimba furnizorul, iar clauza care guvernează acel moment se scrie când toată lumea este prietenoasă și se citește când nu mai este nimeni. Ea ar trebui să spună limpede patru lucruri.

Cine deține codul, inclusiv modulele proprii și munca la temă, și sub ce licență. Unde stă depozitul și cum se transferă accesul. Că un export complet al bazei de date, al fișierelor și al configurației va fi livrat într-un format declarat, într-un număr declarat de zile lucrătoare. Și că DNS-ul, găzduirea și acreditările serviciilor terțe se predau, nu se rețin.

Modul în care se strică nu este de obicei reaua-credință. Este un furnizor care vă găzduiește site-ul pe contul lui, ține singura copie a depozitului și răspunde în șase săptămâni pentru că nu mai sunteți client plătitor. Cereți clauza de ieșire înainte să semnați și tratați orice ezitare drept informație.

Drupal 7: sfârșitul vieții, suportul extins și distanța dintre ele

Suportul de securitate pentru Drupal 7 s-a încheiat pe 5 ianuarie 2025 . Comunitatea a încetat să producă patch-uri, iar uriașul ecosistem de module contribuite care făcea Drupal 7 util a încetat să mai fie întreținut odată cu el.

Drupal Association operează un Extended Security Support Provider Program, iar HeroDevs și Tag1 Consulting sunt furnizorii certificați în cadrul lui. Cumpărarea acelui suport este o decizie legitimă pentru o organizație care chiar nu poate migra anul acesta și este vizibil mai bună decât nimic.

Ce nu face este să facă site-ul sigur în sensul obișnuit. Un furnizor comercial repară vulnerabilitățile pe care le găsește sau despre care i se spune, după propriul calendar, pentru setul de module pe care a acceptat să îl acopere. Nu reface procesul public de avize, nu acoperă fiecare modul contribuit pe care se întâmplă să îl aveți instalat și nu se extinde la bibliotecile externe de care depind acele module. Suportul extins este un mod controlat de a rula o platformă nesusținută, iar un contract de suport nu este sinonim cu a fi în siguranță.

Dacă sunteți pe Drupal 7 în septembrie 2026, sfatul onest este să dați banii pe migrare, nu pe chirie. Ghidul nostru din 2026 pentru dezvoltarea web cu Drupal descrie platforma așa cum este, iar detaliul despre procesul avizelor stă în nota noastră despre securitatea Drupal, avize și risc real .

Suportul editorial și bugetul de modificări

Două elemente sunt scoase din contractele de suport pentru că sunt greu de delimitat, iar ele sunt exact cele pe care clienții le observă.

Suportul editorial înseamnă cineva care poate adăuga un tip de conținut, repara un view care a încetat să filtreze corect, reinstrui un editor după o schimbare de personal sau afla de ce un stil de imagine taie fețele. Este puțin spectaculos și foarte frecvent, iar un contract fără el produce un client care încetează să mai ceară și începe să ocolească site-ul.

Bugetul de modificări este cealaltă jumătate. Orice site adună o coadă de lucrări mici: un câmp într-un formular, o redirecționare după mutarea unei pagini, o schimbare a celui care primește cererile. Declararea unei alocări lunare în ore pentru acea coadă este ceea ce o împiedică să devină un proiect de urgență trimestrial. Două până la patru ore pe lună este o cifră realistă pentru un site mic, 8 sau 16 pentru unul aglomerat.

Cât costă suportul Drupal în Marea Britanie

Cifrele de mai jos sunt estimările noastre interne pentru 2026, bazate pe munca agențiilor britanice, nu pe un studiu publicat. Ele presupun un furnizor care face cele opt activități descrise mai sus, nu un abonament de monitorizare cu o căsuță de suport atașată.

În proză: un site mic de prezentare stă la circa £250 până la £600 pe lună, ceea ce cumpără monitorizarea avizelor, un ciclu lunar de patch-uri, verificarea backupurilor și o oră sau două de modificări. Un site mediu cu integrări ajunge la aproximativ £700 până la £1,800, pentru că fiecare integrare adaugă o suprafață de regresie retestată după fiecare actualizare de nucleu. Un site complex sau multilingv cu module proprii pornește de la circa £2,000 și ajunge la £6,000 sau mai mult.

Înțelegerile de monitorizare simplă, în care furnizorul urmărește avizele și vă spune ce vă privește, dar nu livrează nimic, stau mai jos, la circa £250 până la £450 pe lună. Puse lângă tarifele zilnice ale agențiilor britanice, de £600 până la £900, un contract de £1,500 cumpără aproape două zile de inginer. Detaliul despre tarife stă în nota noastră despre tarifele, competențele și verificarea unui dezvoltator Drupal , iar imaginea bugetară mai largă în costul mentenanței software .

Ce mută un site dintr-un interval în următorul

Instinctul este să prețuiești suportul după trafic, iar traficul este aproape irelevant. Un site care servește 200.000 de vizite pe lună cu douăzeci de module și fără integrări este mai ieftin de întreținut decât unul care servește două mii cu un conector CRM, un procesator de plăți și o migrare proprie.

Trei lucruri conduc de fapt costul. Numărul de module, pentru că fiecare modul contribuit este un flux de avize de urmărit și un risc de compatibilitate la fiecare actualizare de nucleu. Numărul de integrări, pentru că fiecare este un contract extern care se poate schimba sub voi și un test de regresie care trebuie reluat. Și volumul editorial, pentru că o redacție activă generează constant întrebări de suport, schimbări de permisiuni și ajustări ale modelului de conținut.

Codul propriu este multiplicatorul pe toate trei. Un site cu 12.000 de linii de cod în module proprii are nevoie de o scanare a deprecierilor și de o trecere de regresie la fiecare lansare minoră, adică o zi de muncă pe care un site pur contribuit nu o are. De aici vine intervalul de sus, iar aceasta este munca pe care proiectele noastre de dezvoltare software sunt de obicei chemate să o preia.

Întrebări pentru un posibil furnizor

Șase întrebări și răspunsurile care ar trebui să vă îngrijoreze.

Pe ce versiune de Drupal și de PHP rulează site-ul nostru acum și care este drumul de actualizare? Un răspuns care cere să se uite mai întâi este în regulă. Un răspuns care vine peste o săptămână nu este. Cum aflați că un aviz de securitate ne privește? “Urmărim drupal.org” este slab; un inventar de module per site este răspunsul dorit.

Descrieți-mi procesul vostru de lansare. Ezitarea aici este cel mai puternic semnal negativ din toată discuția. Când ați restaurat ultima dată acest site dintr-un backup? “Facem backupuri zilnice” nu este un răspuns la întrebare. Ce este exclus din contract și cum decideți dacă ceva este defecțiune sau modificare? Și, în final: dacă plecăm, ce primim și cât de repede?

Ce se întâmplă când nu există contract

Aceasta este mai degrabă o succesiune decât un avertisment și se desfășoară cam în același ritm pe orice site Drupal fără suport.

În primele luni nu se întâmplă nimic, și tocmai asta este problema, pentru că îi învață pe toți că nu trebuie să se întâmple nimic. Undeva între luna a șasea și a douăsprezecea, restanța de actualizări trece de punctul în care actualizările încetează să fie sigure una câte una, fiindcă un modul cere acum un nucleu mai nou, care cere un PHP mai nou, pe care găzduirea nu îl oferă. Aplicarea unui patch a devenit un proiect.

Apoi site-ul iese complet din suportul platformei, iar o schimbare de browser sau de PHP strică ceva vizibil. Reparația începe acum cu o actualizare pe care nimeni nu a bugetat-o, ofertată ca lucrare de urgență, iar părțile fără documentație sunt reconstruite, nu reparate. Dacă pe drum apare o breșă și sunt implicate date personale, ICO așteaptă notificarea în 72 de ore de la aflarea ei, atunci când breșa riscă să afecteze drepturile și libertățile persoanelor, iar acesta este un termen pe care îl respectați cu jurnale și backupuri pe care fie le aveți, fie nu.

Nota de plată a recuperării valorează, fără greș, de câteva ori contractul care ar fi prevenit-o, iar diferența nu este manopera. Este că munca planificată are loc marți, cu un plan de revenire, iar munca de urgență duminică, fără.

Stabilirea corectă a ariei înainte de semnare

Rostul a tot ce s-a spus nu este să vă facă neîncrezători în furnizori. Este să facă semnificativă comparația între două oferte, pentru că astăzi cele mai multe oferte de suport Drupal sunt incomparabile prin construcție: cuvinte diferite, excluderi diferite și nicio definiție comună a ceea ce înseamnă munca lunară.

Luați cele opt activități, intervalele de risc Drupal, cele trei modele de contract și cele șase întrebări și puneți-le lângă ce aveți pe birou. Ce supraviețuiește este o ofertă adevărată.

Mecanik susține site-uri Drupal ca parte a muncii noastre de dezvoltare de site-uri web și dezvoltare software , iar primul angajament este de obicei un inventar, nu o reparație, pentru că majoritatea site-urilor care ajung la noi nu pot spune care dintre modulele lor mai sunt acoperite de fluxul avizelor de securitate .

Întrebări frecvente

Ce ar trebui să includă un contract de suport Drupal? Opt activități: monitorizarea avizelor de securitate față de setul vostru exact de module, actualizări de nucleu și de module contribuite pe un ciclu definit, actualizări de dependențe și de platformă PHP, verificarea backupurilor cu restaurări testate, monitorizarea disponibilității și a erorilor de aplicație, verificări ale regresiilor de performanță, suport editorial și un buget de modificări declarat în ore. Un contract care numește doar patru este incomplet, iar cele patru care lipsesc de obicei sunt testarea restaurării, verificările de performanță, actualizările de platformă și bugetul de modificări.

Cât costă lunar suportul Drupal în Marea Britanie? Ca estimare internă pentru 2026, un site mic de prezentare costă aproximativ £250 până la £600 pe lună, un site mediu cu una sau două integrări £700 până la £1,800, iar un site complex multilingv cu module proprii £2,000 până la £6,000. Înțelegerile de monitorizare simplă stau la circa £250 până la £450. Față de tarifele zilnice ale agențiilor britanice de £600 până la £900, un contract de £1,500 cumpără aproape două zile de inginer.

Când publică Drupal patch-urile de securitate? Lansările de securitate ale nucleului Drupal ies într-o fereastră în a treia miercuri a lunii, începând la 1200 America/New York, adică 1600 sau 1700 UTC, în funcție de sezon. Proiectele contribuite au o fereastră de securitate în fiecare miercuri. Lansările extrem de critice ale nucleului sunt precedate de un anunț de serviciu public, ca proprietarii de site-uri să își poată aranja acoperirea din timp.

Suportul extins pentru Drupal 7 înseamnă același lucru cu a fi în siguranță? Nu. Suportul de securitate pentru Drupal 7 s-a încheiat pe 5 ianuarie 2025, iar Drupal Association certifică HeroDevs și Tag1 Consulting în cadrul programului său Extended Security Support Provider Program. Acei furnizori repară ce acoperă, după propriul calendar, pentru un set de module convenit. Asta nu reface procesul public de avize, nu acoperă fiecare modul contribuit pe care îl aveți instalat și nu se extinde la bibliotecile externe.

Când ajunge Drupal 10 la sfârșitul vieții? Drupal 10 ajunge la sfârșitul vieții pe 9 decembrie 2026, în aceeași săptămână în care apare Drupal 12, începând cu 7 decembrie 2026. Suportul de securitate pentru ramurile 11.3.x și 10.6.x se încheie în același moment. Drupal 12 suportă exclusiv PHP 8.5, deci site-urile pe versiuni mai vechi de PHP au nevoie de o schimbare de găzduire înainte de actualizare, nu după.