Checklist di prelancio server di Produzione

Lanciare un nuovo sito o una piattaforma è sempre un passo importante per una azienda. Se poi l'hype sulla applicazione è stato importante ci sono grossi rischi di avere un sovraccarico di risorse sul server che se non è stato impostato e gestito correttamente, rischia di trasformarsi in un continuo errore.

Questa checklist è stata fatta per gestire il lancio di una applicazione e per avere tutti gli strumenti di gestione e verifica del server pronti per l'analisi e il debug.

 

Controlli con fornitore di servizi dominio

• Aggiungere un Load Balancing DNS per HAProxy
• Diminuire il TTL per il sottodominio primario (60-300s)
• Diminuire il TTL per il record SOA DNS (60-600s)

Controlli sul server

• Creare gli account utente per gli utilizzatori del server
• Creare un account per il deploy dell'applicazione
• Aggiungere le chiavi SSH pubbliche
• Disabilitare l'autenticazione SSH via password
• Disabilitare il login root SSH
• Disabilitare il login SSH attraverso Reverse DNS Lookup
• Cambiare la porta di accesso SSH (non usare la standard 22)
• Disabilitare l'accesso SSH al di fuori della rete interna
• Usare un server proxy o una vpn per la connessione
• Abilitare il firewall ufw e bloccare le porte non usate
• In caso si utilizzi Amazon EC2, sfruttare le potenzialità dei gruppo di sicurezza
• Configurare /etc/resolv.conf per diminuire i timeout
• Installare nscd
• Installare fail2ban
• Installare htop,systat,strace,ack-grep,vim e altri software di debug

Bilanciamento di carico

• Configurare e rendere sicuro HAProxy Web Ui
• Verificare che gli Health Checks di HAProxy siano funzionanti
• Verificare che HAProxy si apra con il riavvio del server
• Verificare le impostazioni di timeout per il server pool
• Testare HAProxy failover con keepalived
• Aumentare il valore net.core.somaxconn a 9999999
• Settare net.ipv4.tcp_tw_recycle a 1
• Settare net.ipv4.tcp_ip_local_port_range a 10240 62000
• Verificare che le modifiche su sysctl rimangano con i riavvii del server

Bilanciamento di carico

• Verificare che PHP-FPM si apra con il riavvio del server
• Verificare di aver settato pm.max_children sul file di configurazione
• Settare Logrotate per i file di log Nginx /Apache
• Settare Logrotare per PHP-FPM
• Verificare che APC o Zend Opcache sia settato nel file php.ini
• Se si usa APC, verificare apc.stat_ctime=1
• Montare il filesystem con noatime option
• Abilitare tmpfs per la cartella /tmp
• Verificare le impostazioni su php.ini expose_php=Off, memory_limit=-1,max_execution_time=5,display_errors=Off
• Installare l'estension igbinary PECL
• Installare l'estensione memcached PECL
• Installare l'estensione redis PECL
• Impostare Capistrano per i deploy

Database Server

• Verificare di avere l'ultima versione aggiornata di Percona SQL
• Verificare i permessi utente
• Verificare ove possibile che MySQL sia in ascolto solo su rete locale e non sia esposto alla rete pubblica
• Mettere gli slave Mysql dietro HAProxy
• Settare pt-kill per fermare le query orfane e verificarne il comportamento dopo un reboot
• Verificare max_connections sia settato ad un numero maggiori del numero dei worker php-fpm
• Verificare innodb_flush_method=0_DIRECT
• Verificare innodb_buffer_pool_size sia 90% della memoria server
• Verificare query_cache sia disabilitato (query_cache_seize=0, query_cache_type=0)
• Sul database master, verificare innodb_flush_log_at_trx_commit=1
• Sul database slave, verificare innodb_flush_log_at_trx_commit=2
• Verificare che tutte le tabelle stiano usando InnoDB come storage engine
• Cambiare il Linux I/O scheduler a deadline o noop
• Cambiare le impostazioni vm.swapiness systctl
• Verificare che la partizione del database mysql stia usando XFS filesystem
• Verificare che siano impostati i backup di Mysql
• Gestire in modo corretto la terminazione degli slave server

Redis Cache

• Abilitare Append-Only File (AOF)
• settare maxmemory
• Verificare che la maxmemory-policy sia adatta all'uso
• Fare in modo che Redis sia in ascolto solo localmente e non su rete pubblica (dove possibile)
• Verificare che redis si apra correttamente al riavvio del server

Resque-Server

• Verificare che Resque Web UI sia online e bloccato da username e password
• Verificare che i workers Resque siano attivi
• Verificare che Resque sia apra correttamente al riavvio

Accortezze sul codice

• Gestire il "Dogpile effect"
• Caricare più cose possibile usando Memcached
• Spostare i task più lunghi, le chiamate API e qualsiasi cosa possa essere postposto in una coda asincrona
• Verificare chei job in background abbiano una gestione corretta del numero massimo di esecuzione in caso di errore (MAX_ATTEMPTS)
• Verificare che l'ORM o la libreria del databsse possano splittare le query fra i master e gli slave
• Usare strumenti come xhprof, xdebug o microtime per profilare eventuali errori nel codice.
• Settare airbrake, new relic o exceptional per scrivere nei log e lanciare avvisi