Guida Imparare dagli errori altrui. Perchè un progetto fallisce?

Stato
Discussione chiusa ad ulteriori risposte.

iltizio

Utente Emerald
1 Novembre 2009
929
60
533
598
Ultima modifica:
Buonasera Inforge,
in questa discussione vorrei elencare quali sono le cause che portano al fallimento di un progetto di Metin2 e relativi esempi. Lo scopo è quello di imparare dagli errori altrui, dato che i player spesso non ci danno la possibilità di imparare dai nostri e rimediare.

Per creare un elenco più dettagliato possibile con le soluzioni per evitare questi problemi vi invito tutti ad esprimere la vostra opinione e ad elencare eventuali esempi. Assieme vedremo di capire quali sono le cause e come prevenirle e se possibile come risolverle.

Ad ogni esempio riportato chiedo di linkare il thread della presentazione ufficiale del progetto e di taggare l'admin o founder sia per renderlo a conoscenza e sia per invitarlo a dare più informazioni, confermare la causa del problema e renderlo partecipe alla ricerca della soluzione.



Problemi riguardo allo staff
Molti staff vengono spesso additati dall'utenza come incompetenti, poco attenti e mal organizzati e a lungo andare porta all'abbandono da parte dei player.

Un buon team deve essere ben organizzato, con una persona dedicata all'organizzazione interna. Questo Team Manager deve dedicare molto tempo alla formazione dei membri dello staff, alla stesura delle regole interne e un unico modo di operare per tutti i membri dello staff. Inoltre devono essere specificati i ruoli e i doveri associati ad ognuno di essi e pubblicati sulla board ufficiale.

Inutile dire che non vanno MAI concessi favoritismi neanche piccoli, altrimenti si andrebbe a creare un precedente.

La scelta dello staff e assegnazione dei ruoli è un altro degli aspetti fondamentali. E' un grosso rischio scegliere male un membro dello staff e ufficializzarlo. Non è facile ma con le dovute precauzioni si può ridurre la possibilità di dare la possibilità di fare danno a un collaboratore. Bisogna innanzitutto scegliere con attenzione e calma. Evitate di scegliere lo staff all'ultimo momento. Create un modello univoco per le candidature con più informazioni possibili per poterle confrontare meglio tra loro e valutare il migliore.

Prendere più persone del necessario, senza esagerare, per avere sempre la possibilità di andare avanti quando uno lascia o lo dovete allontanare.

A progetto in fase di sviluppo cercate di rendere partecipi gli altri membri dello staff non strettamente necessari al completamento del progetto. Dategli qualche lavoretto e valutateli su quello. Inoltre sudandoci, avranno più a cuore il progetto.

Amministratori e consulenti

Una delle cause principali del fallimento di molti progetti di ogni tipo è la scelta degli amministratori fissi che provvedono al mantenimento tecnico del progetto.
Hanno il compito di rendere il progetto unico e piacevole all'utenza, ma allo stesso tempo sicuro ed efficiente.

Non c'è un numero massimo o minimo di amministratori, ma servono delle competenze che se mancanti possono essere integrate con consulenti esterni a pagamento.

Indipendentemente dal tipo di progetto è necessario disporre almeno delle seguenti competenze:

  • Applicativo: la persona con un minimo di competenze di programmazione e utilizzo di sistemi unix (FreeBSD) che ha il compito di installare componenti applicative, configurazioni e un primo troubleshooting applicativo.
  • Sistemista: colui che gestisce interamente gli aspetti dell'infrastruttura, dalla scelta dell'hardware e software fasandosi con le esigenze degli applicativi e l'amministrazione dei sistemi. Deve gestire l'aspetto sicurezza lato server, backup, ridondanza, piani di ricovery, DBA e la consueta amministrazione di sistema. In una realtà aziendale ben strutturata, questa figura non potrebbe essere unica ma divisa con più persone specializzate (Backup, Sistemi Unix, DBA, Security)
  • Team Manager: non necessariamente un tecnico. Deve scegliere, organizzare e gestire lo staff.
  • Progettista gameplay: non necessariamente un tecnico. Deve organizzare il gameplay affinchè il gioco possa essere competitivo con la concorrenza.
Queste sono le 4 figure minime che possono essere anche riunite in un'unica persona, anche se piuttosto difficile e sconsigliabile. Persone che abbiano tutte queste competenze possono esserci, ma difficilmente hanno anche il tempo per fare tutto.
Per progetti più complessi possono essere necessarie altre figure come sviluppatori (client e server), webmaster, grafici (2D e 3D) e addetti alle pubbliche relazioni, oltre allo staff di supporto (GM, MOD, EM).

La mancanza di queste figure possono essere sostituite con consulenti esterni, che con la loro esperienza e competenza approfondita sono in grado di dare un supporto rapido e di qualità alla parte amministrativa, se scelti bene. L'unica figura che non può essere sostituita da un consulente è quella del Team Manager.

Come tutti i membri dello staff, anche il team di amministrazione deve essere affidabile, corretto e scelto con molta cautela.


Accessi e permessi
Ogni membro dello staff e del team di amministrazione deve avere i giusti permessi e accessi per evitare problemi volontari o involontari.

Nel caso dello staff di supporto il Team Manager deve assegnare i giusti poteri sulle varie piattaforme. Board, game e sistemi di supporto esterni (ticket, chat) possono gestire i permessi o poteri assegnati ad ogni ruolo. Un GM o un MOD deve avere i giusti permessi per eseguire il compito a lui assegnato, non di più.

Nel caso degli amministratori, molti permettono l'accesso completo a tutti i sistemi e piattaforme indistintamente e indipendentemente dalle competenze del singolo.
Dare gli accessi solo in base alla fiducia non è sufficiente, devono essere assegnati accessi e relativi permessi solo a chi di competenza e ruolo.
Qualche esempio:

  • Il sistemista deve avere gli accessi completi ai sistemi (root) a lui assegnati e dare i permessi a seconda dei ruoli ed esigenze agli altri amministratori. Pur avendo la possibilità, non deve mettere mano agli applicativi in gestione alle persone di competenza.
  • L'addetto all'applicativo non deve avere l'accesso completo ai sistemi, ma un utenza limitata in grado di gestire solo gli applicativi a lui assegnati. In caso di modifiche al sistema
  • Il team manager non ha necessità di accedere ai sistemi. L'unico permesso che può avere è l'assegnazione dei ruoli e vista dei log di sicurezza se correttamente limitato a quello (permission sulle tabelle mysql o pannello di controllo)
  • Lo sviluppatore deve lavorare unicamente sui sistemi di sviluppo ed eventualmente su quello di test, ma non ha necessità di lavorare direttamente sul sistema di produzione. Dovrà fornire il necessario all'addetto agli applicativi che applica gli aggiornamenti.
Riguardo ai consulenti esterni valgono le regole sopra indicate, ma con una cautela maggiore e accessi temporanei.

Per gestire meglio gli accessi ai sistemi è consigliabile utilizzare un sistema ponte con un utenza nominale per ogni amministratore avente diritto ad accedere, e assegnargli i relativi permessi. Per semplicità e allo stesso tempo sicurezza possono essere usate le chiavi ssh in caso di un sistema Unix.

I backup o una loro copia devono essere accessibili solo dalle persone strettamente affidabili come il fouder.

Le azioni devono essere loggate in base all'utenza su una zona non accessibile alle persone non addette.

Perdita di dati

La perdita di dati per fortuna sta calando, grazie alle nuove tecnologie e risorse più accessibili.

Macchine potentissime e costose non sono sufficienti a impedire la perdita di dati, bisogna attuare soluzioni anche a livello software.


Per prima cosa i backup: vanno eseguiti alla giusta frequenza, automatici, copiati su supporto remoto e fatti in modo che possano essere ripristinati rapidamente e con la possibilità di ripristinare solo la parte che serve. Testate ogni tanto i backup per vedere se si ripristinano senza problemi. Eseguite qualche prova di restore, sia per verificare l'effettiva completezza dei backup, sia per allenarvi ad eseguire un restore rapidamente quando ce ne sarà bisogno.
Per Metin2 vanno eseguiti questi 4 backup:

  • Snapshot della macchina se è una VM/VPS. Bassa frequenza (1 a settimana).
  • Fileserver. Frequenza media (1 al giorno).
  • Datafile (/var/db/mysql). Da usare solo quando non c'è altra possibilità. Frequenza medio-alta (2 volte al giorno).
  • Dump dei db. Create un dump per ogni db e comprimeteli. Frequenza alta (più volte all'ora).

Un 'altra cosa da fare è l'aggiornamento del dbms e storage engine alle nuove versioni. Evitate di rimanere alla versione di inizio 2000. https://www.inforge.net/xi/posts/4464790/

Se ne avete la possibilità configurate il raid dei dischi. La possibilità che un disco si guasti anche solo per usura è da tenere conto. Inoltre cercate di scegliere una macchina fisica moderna con hardware nuovo.

Utilizzare correttamente i filesystem: create più filesystem e se potete utilizzate gli ZFS. https://www.inforge.net/xi/threads/...gurare-una-macchina-server-per-metin2.451780/

Crash applicativi
In caso un'applicativo fondamentale come il game server o mysql crashi potrebbe creare grossi problemi, e se non monitorato o se un amministratore non è disponibile per sistemare il problema si rischia di aumentare il danno.

Monitoraggio. Utilizzate un buon sistema di monitoraggio che vi permette di localizzare rapidamente i problemi e ve li segnali prima degli utenti. Vi consiglio di utilizzare Check_mk e configurarlo a dovere. https://www.inforge.net/xi/threads/...gurare-una-macchina-server-per-metin2.451780/

Assicuratevi che se un servizio crasha tenti autonomamente di restartarsi. Configurate un sistema di autorestart dei core e di mysql, anche in caso di un riavvio inaspettato della macchina.

In caso non riusciate a restartare tutto correttamente seguite il corretto flusso di troubleshooting. Prima di andare in panico e di dare la colpa agli hackers verificate tutti i log, anche quelli di sistema e verificate l'occupazione dei filesystem.

Verificate anche l'occupazione delle risorse quali ram e cpu.


Crash sistema
Se la macchina si riavvia da sola o non torna più su è un problema grave e di natura diversa.

Per prima cosa non date subito la colpa al provider e se riuscite ad accedere alla macchina fate qualche verifica. Leggete per prima cosa i log di sistema sotto /var/log e verificate l'occupazione dei filesystem e status. Potreste trovare sia errori software che hardware.

L'unica prevenzione efficace è la ridondanza: https://www.inforge.net/xi/threads/...gurare-una-macchina-server-per-metin2.451780/

Inoltre assicuratevi anche di avere un buon supporto rapido e capace, e sopratutto che provveda a sostituire l'hardware guasto in tempi ragionevoli. Cercate di essere collaborativi con il supporto e preparatevi a dovergli dare gli accessi e/o spegnere la macchina per delle ore.

Backup remoti e ridondanza vi possono salvare da un disastro del genere che altrimenti può essere irreparabile.

Lag

Situazione ancora molto frequente dove non è facile trovare la causa e/o risolvere.

Non incominciate a dare automaticamente la colpa ai DDoS.

Può essere un problema server, client, rete, ram, cpu, disco, applicativo o attacco malevolo.

In base alle segnalazioni e ai test che fate, verificate se è un problema comune o isolato per escludere un problema lato server.
Se le segnalazioni sono limitate ad alcune mappe, mob o situazioni può essere un problema client (grafica troppo pesante) o di mal programmazione (server).
Se è un problema comune valutate un problema di rete, prestazioni o attacco. Tutte e tre le cose possono verificarsi.
La macchina appena cercate di salire potrebbe risultare bloccata o visibilmente lenta. Verificate i processi attivi, le connessioni, l'utilizzo totale della ram e cpu e l'utilizzo della rete. Se non riuscite a trovare una soluzione delicata o rapida, valutate il reboot della macchina per guadagnare un po' di tempo, ma non limitatevi a questo.
Se la macchina è sottodimensionata, cioè non ha abbastanza capacità di rete, cpu e ram valutate una migrazione su sistema più potente.

Verificate anche mysql. Potrebbero esserci troppe connessioni e tempi di esecuzione lunghi. Valutare quindi un tuning.

Un buon sistema di monitoraggio può anticiparvi un rallentamento della macchina con conseguenti lag o crash.
La ridondanza può aiutare anche in questo caso.

Bug

Metin2 è famoso per i numerosi bug anche nei server ufficiali, del resto è made in china. Oltre ai bug originali possono essere presenti altri bug dovuti ad implementazioni. Per cui un new style è più soggetto a problemi del genere.

Cercate sempre di fare un periodo di beta, specialmente se è un new-style con molte implementazioni.

Mano a mano che implementate qualcosa fatelo testare.

Le implementazioni e successivi test vanno fatti prima su una macchina dedicata ai test e poi rilasciati su quella di produzione. Cercate di applicare anche le più piccole modifiche prima all'ambiente di test, per maggior sicurezza, verifica di eventuali contrasti tra altre funzionalità e per tenere sempre aggiornato anche l'ambiente di test.

La raccolta di segnalazioni di bug deve essere organizzata bene per non perdersi niente e per non buttar via del tempo.
Un semplice file su cloud con l'elenco delle segnalazioni sistemate o no può essere sufficiente.

Fate in modo che i player non abbiano difficoltà a segnalare i bug. Sfruttate più possibilità di supporto, online e offline.

Supporto

Si lega al primo punto trattato. Un buon sistema di supporto rende non solo più comoda la permanenza dei vostri utenti, ma anche un più semplice ed efficace lavoro da parte dello staff incaricato.

Creare e gestire bene il forum. Se fatto bene permette ai giocatori di supportarsi a vicenda. Per fare ciò il forum deve essere ben popolato e gestito. Puntate molto su questo.

Create guide e F.A.Q. e rendetele facilmente reperibili. Inoltre abituate gli utenti a consultarle e a non dipendere sempre dal GM online.

Organizzare la comunicazione utente e staff. L'utente deve porter comunicare sempre con lo staff. Create sistemi che permettono la comunicazione anche fuori dal game e offline. Valutate ticket, chat sul sito e email.

Ordine. I sistemi di supporto devono permettere di rendere il tutto ordinato e facilmente gestibile da parte degli utenti e dello staff.
Dividete in categorie le richieste tramite ticket per assegnarle al gruppo giusto in modo rapido. Idem per forum e chat sul sito.

Cercate di fare in modo di tenere traccia delle conversazioni tra staff e utenti.

Valutare se vietare la chat privata tra staff e player on game e sostituirla con una sul sito, come fanno attualmente tutti gli altri giochi online.

Sicurezza

Molti progetti chiudono per colpa di qualche ragazzino invidioso o che vuole fare il figo credendosi hacker.
Qualche piccola attenzione può bastare a bloccare questi piccoli hacker.

Protezione degli accessi. Evitate di limitarvi a utilizzare una password complessa. Sfruttate firewall, cifratura, chiavi, bind e utenze limitate e diverse per ogni uso.

Evitate buchi.

Configurate bene il firewall. Se potete utilizzate un appliance fornitovi dal provider, altrimenti utilizzate quello integrato nel sistema operativo.

Limitare la banda. Metin2 non usa una grande velocità di banda. Se la limitate evitate che un DDoS vi inchiodi la macchina a livello di cpu e ram.

Limitate i servizi di rete sull'interfaccia pubblica. Non installate un webserver dove c'è il game server.

Trovate una buona protezione DDoS e se potete personalizzatela per il vostro server di metin2.

Se possibile utilizzate un sistema ponte che si collega attraverso un interfaccia di rete dedicata e privata.

Utilizzare macchine virtuali.

Altri consigli qua: https://www.inforge.net/xi/threads/...gurare-una-macchina-server-per-metin2.451780/


Esempi di progetti falliti, in fallimento o che hanno avuto problemi

 
Molte volte accade perchè gli accessi alle macchine vengono sputtanati ai quattro venti e così facendo non si potrà mai sapere da dove parte il problema di fondo.
 
i problemi nascono per il 99,9% dei casi da uno staff scelto cosi alla boia d'un giuda
 
i problemi nascono per il 99,9% dei casi da uno staff scelto cosi alla boia d'un giuda
Tutti i casi qui sopra sono dovuti dallo staff. Ho semplicemente approfondito cosa vuol dire "Colpa dello staff" in realtà e i vari casi.
La scelta dello staff non è sufficiente.
 
Te lo dico per esperienza.
Non saper mettere in sicurezza un server è come dare le chiavi di casa ad una persona sconosciuta.
Dareste mai le chiavi di casa ad una persona che non conosci?
Il Saper fixare tutte le falle esistenti , è un pregio.
Ma ci vuole tanta pazienza e buona volontà.
Per lo staff avrei da ridire.
QUesto problema avviene perchè ci si fida troppo di persone che non hanno le dovute competenze tecniche ecc ecc.
saper far una buona selezione fà parte di essere responsabili che spesso le persone non hanno.
 
  • Mi piace
Reazioni: iltizio
Sei bravo a giudicare, dato che hai queste grandi conoscenze perchè non apri te un server e poi ci fai fare due risate?!
Mi sa che non hai capito il senso di questo thread. Non sono qui a giudicare, ma a riportare le cause ed esempi di fallimenti al fine di evitarne di futuri. Chi ha avuto esperienze passate e ha vissuto a sue spese questi problemi non dovrebbe più aver bisogno di leggere questo thread se non per confermare o aggiungere.
Se sei tra questi evita di scrivere post senza senso tanto per aumentare i messaggi e scrivi qualcosa che possa essere utile a qualcuno.

Te lo dico per esperienza.
Non saper mettere in sicurezza un server è come dare le chiavi di casa ad una persona sconosciuta.
Dareste mai le chiavi di casa ad una persona che non conosci?
Il Saper fixare tutte le falle esistenti , è un pregio.
Ma ci vuole tanta pazienza e buona volontà.
Per lo staff avrei da ridire.
QUesto problema avviene perchè ci si fida troppo di persone che non hanno le dovute competenze tecniche ecc ecc.
saper far una buona selezione fà parte di essere responsabili che spesso le persone non hanno.
Parole sante. Dipende tutto dallo staff, non ci sono storie.
I collaboratori vanno scelti accuratamente, ma non ci si può limitare a qualche riga in un messaggio di candidatura. Ogni membro dello staff dal GM al GA vanno anche testati. Può capitare che all'inizio sembra super competente e con esperienza, poi scopri che non ha voglia di fare niente e quel poco che fa lo fa male. L'unico modo per evitare questa spiacevole situazione è metterlo alla prova qualunque sia il suo ruolo e qualunque sia lo stato del progetto.
 
.
Parole sante. Dipende tutto dallo staff, non ci sono storie.
I collaboratori vanno scelti accuratamente, ma non ci si può limitare a qualche riga in un messaggio di candidatura. Ogni membro dello staff dal GM al GA vanno anche testati. Può capitare che all'inizio sembra super competente e con esperienza, poi scopri che non ha voglia di fare niente e quel poco che fa lo fa male. L'unico modo per evitare questa spiacevole situazione è metterlo alla prova qualunque sia il suo ruolo e qualunque sia lo stato del progetto.
Ecco., è quello che penso e dico.
 
Stato
Discussione chiusa ad ulteriori risposte.