{"id":38441,"date":"2019-10-31T22:23:44","date_gmt":"2019-10-31T19:23:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/hvatit-dumat-chto-sla-vas-spaset-ono-nuzhno-chtoby-uspokoit-i-sozdat-lozhnoe-chuvstvo-bezopasnosti\/"},"modified":"2019-10-31T22:23:44","modified_gmt":"2019-10-31T19:23:44","slug":"hvatit-dumat-chto-sla-vas-spaset-ono-nuzhno-chtoby-uspokoit-i-sozdat-lozhnoe-chuvstvo-bezopasnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hvatit-dumat-chto-sla-vas-spaset-ono-nuzhno-chtoby-uspokoit-i-sozdat-lozhnoe-chuvstvo-bezopasnosti","title":{"rendered":"Smetti di pensare che lo SLA ti salver\u00e0. Serve solo a tranquillizzare e a creare un falso senso di sicurezza.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Smetti
\n
\nL'SLA, noto anche come \u00abservice-level agreement\u00bb, \u00e8 un accordo-garanzia tra il cliente e il fornitore di servizi riguardo a ci\u00f2 che il cliente ricever\u00e0 in termini di assistenza. In esso sono anche specificate le compensazioni in caso di inattivit\u00e0 imputabile al fornitore e cos\u00ec via. In sostanza, l'SLA \u00e8 una lettera di credenziali, attraverso la quale il data center o il provider di hosting convince il potenziale cliente che ricever\u00e0 un trattamento privilegiato. Il problema \u00e8 che nell'SLA possono essere scritte molte cose e gli eventi descritti in questo documento non si verificano molto spesso. L'SLA non \u00e8 affatto un parametro di riferimento nella scelta di un data center, e non \u00e8 saggio contare su di esso. <\/p>\n

Tutti noi siamo abituati a firmare contratti che impongono obblighi specifici. Anche l'SLA non fa eccezione: \u00e8 solitamente il documento pi\u00f9 distaccato dalla realt\u00e0 che si possa immaginare. Forse l'unico pi\u00f9 inutile \u00e8 il NDA in giurisdizioni dove il concetto di \u00absegreto commerciale\u00bb non esiste realmente. Il problema principale \u00e8 che l'SLA non aiuta affatto il cliente a fare una scelta corretta del fornitore, ma serve solamente a gettare polvere negli occhi. <\/p>\n

Cosa scrivono pi\u00f9 frequentemente i fornitori di hosting nella versione pubblica del SLA? La prima frase riguarda il termine \"affidabilit\u00e0\" dell'hosting, che di solito si traduce in numeri che variano dal 98% al 99,999%. In sostanza, questi numeri sono solo belle invenzioni dei marketer. Un tempo, quando l'hosting era giovane e costoso, e il cloud era solo un sogno per gli specialisti (come l'accesso a banda larga per tutti), il tasso di uptime era estremamente importante. Oggi, con tutti i fornitori che utilizzano pi\u00f9 o meno la stessa attrezzatura, sono collegati alle medesime reti di backbone e offrono pacchetti servizi simili, il tasso di uptime \u00e8 del tutto irrilevante.
\n<\/a><\/noindex><\/p>\n

Esiste davvero un SLA \"corretto\"? <\/h3>\n

\nCerto che esistono versioni ideali di SLA, ma tutte si trattano di documenti non standard e vengono redatte e concordate manualmente tra cliente e fornitore. Questo tipo di SLA riguarda pi\u00f9 comunemente lavori su contratto anzich\u00e9 servizi. <\/p>\n

Cosa deve contenere un buon SLA? In breve, un buon SLA \u00e8 un documento che regola i rapporti tra due soggetti, fornendo a una delle parti (il cliente) il massimo controllo sul processo. In altre parole, nel mondo reale, esiste un documento che descrive i processi globali di interazione e regola le relazioni tra le parti. Stabilisce confini, regole e diventa uno strumento di pressione che entrambe le parti possono utilizzare appieno. Grazie a un SLA ben definito, il cliente pu\u00f2 costringere il fornitore a lavorare come concordato, mentre il fornitore pu\u00f2 difendersi dalle richieste irragionevoli di un cliente troppo insistente. Si presenta cos\u00ec: \u00abNel nostro SLA c'\u00e8 scritto questo e quello, andatevene, facciamo tutto come stabilito\u00bb.<\/p>\n

Quindi, un \u00abSLA corretto\u00bb = \u00abcontratto di servizi adeguato\u00bb e fornisce controllo sulla situazione. E questo \u00e8 possibile solo quando si lavora \u00aballa pari\u00bb. <\/p>\n

Ci\u00f2 che viene scritto sul sito e ci\u00f2 che ci si aspetta nella realt\u00e0 sono due cose diverse.<\/h3>\n

\nIn generale, tutto ci\u00f2 di cui discuteremo in seguito sono trucchi di marketing tipici e un test di attenzione. <\/p>\n

Se consideriamo i popolari fornitori di hosting locali, ogni proposta \u00e8 pi\u00f9 allettante dell'altra: supporto 25\/8, uptime dei server del 99,9999999% del tempo, e una rete di data center in tutta la Russia. Si prega di tenere a mente il punto riguardante i data center, vi torneremo tra poco<\/b>. Ma per ora parliamo della statistica ideale di disponibilit\u00e0 e delle difficolt\u00e0 che si possono incontrare quando il proprio server finisce per trovarsi nell'\u00ab0,0000001% di downtime\u00bb. <\/p>\n

Con percentuali superiori al 98%, qualsiasi interruzione rappresenta un evento al limite dell'errore statistico. L'attrezzatura e la connessione o ci sono o non ci sono. Si pu\u00f2 utilizzare un hosting con un tasso di \u00abaffidabilit\u00e0\u00bb del 50% (secondo il suo SLA) per anni senza alcun problema o \u00abcadere\u00bb una volta al mese per un paio di giorni con quelli che offrono il 99,99%. <\/p>\n

Quando si verifica l'evento di downtime (e ricordiamo, prima o poi, tutti cadono), il cliente deve affrontare la macchina aziendale interna chiamata \u00absupporto\u00bb, e viene alla luce il contratto di servizio e l'SLA. Cosa significa questo:<\/p>\n