Come limitare l'effetto delle modifiche client ai sistemi di produzione

Question

Il nostro negozio ha sviluppato una WEB / SMS / soluzione pochi DB per installazioni dozzina di client. Le applicazioni hanno alcuni requisiti di prestazioni in tempo reale, e sono appena sufficiente per funzionare correttamente. Il problema è che i clienti (proprietari dei server di produzione) stanno utilizzando lo stesso server / database per le personalizzazioni che causano problemi con le prestazioni delle applicazioni che abbiamo creato e implementato.

A pochi esempi di personalizzazioni dei clienti:

• Aggiunta di tabelle di grandi dimensioni con molti tipi di dati di testo per le colonne che vengono espressi per altri tipi di dati nelle query
• Non ci sono chiavi primarie, indici, o vincoli FK
• L'utilizzo di script esterni che utilizzano count(*) from table where id = x, in un ciclo dal copione, per determinare come costruire più query più avanti nello stesso script. (Nessuna azione di massa che il progettista può ottimizzare o semplicemente fare tutto in un solo passaggio)
• vengono creati Tutti i nuovi file di codice sul server / proprietà di root, con 0777 permessi

I clienti non prendono bene suggerimenti / critiche. Se dobbiamo solo andare avanti e cercare di porto / modificare gli script stessi, il vecchio codice può tornare, clobbering eventuali modifiche che facciamo! O con la conoscenza limitata dei loro casi d'uso, rompiamo la funzionalità durante il tentativo di ottimizzare le proprie modifiche.

La mia domanda è questa: come possiamo limitare le risorse per query / applicazioni altro che ciò che creare e distribuire? Ci sono delle opzioni pragmatiche in scenari come questo? Ci vantavano di avere una soluzione OSS, ma sembra che è diventato una passività.

Usiamo PG 8.3 in esecuzione su una serie su Linux Distos. I clienti preferiscono php, ma gli script di shell, Perl, Python, e plpgsql sono tutti utilizzati sul sistema in un modo o nell'altro.

Answer 1

Questo problema è iniziato circa due minuti dopo il primo cliente è stato dato accesso completo al primo computer, e non è andato via da allora. Ogni volta che qualcuno le cui priorità sono sempre orientato al business lavoro fatto in fretta saranno sciatta su di esso e rovinare le cose per tutti. Questo è solo come funzionano le cose, perché il design e l'implementazione corretta sono più difficili di hack basso costo. Non hai intenzione di risolvere questo problema, tutto quello che puoi fare è capire come rendere più facile per il cliente di lavorare con voi che contro di voi. Se lo fate a destra, che sarà simile a un servizio eccellente, piuttosto che fastidioso.

Prima di tutto, la parte del database. C'è ora modo per controllare le risorse query in PostgreSQL. La difficoltà principale è che strumenti come "bella" l'utilizzo della CPU di controllo, ma se il database non rientra nella RAM che può benissimo essere di I / O l'uso che si sta uccidendo. Vedere questo messaggio sviluppatore che riassume le questioni qui

Ora, se in realtà si tratta di CPU i clienti stanno bruciando attraverso, è possibile utilizzare due tecniche per migliorare la situazione:

• Installare una funzione C che cambia la priorità del processo ( esempio 1 , esempio 2 ) e assicurarsi che ogni volta che corrono qualcosa che viene chiamato prima ( forse messo nei loro file di configurazione psql, ci sono altri modi).
• Scrivi uno script che cerca processi postmaster generati dalla loro userid e li renice, farlo girare spesso in cron o come un demone.

Sembra che il tuo problema non sono i particolari processi di query che stanno in esecuzione, ma piuttosto altre modifiche che stanno facendo per la struttura più ampia. C'è solo un modo per far fronte a questo: si deve trattare il cliente come se fossero un intruso e utilizzare gli approcci di quella porzione del campo della sicurezza informatica per rilevare quando si rovinare tutto. Sul serio! Installare un sistema di rilevamento delle intrusioni come Tripwire sul server (ci sono strumenti migliori, questo è solo l'esempio classico), e lo hanno avvisare l'utente quando si toccano nulla. Nuovo file che è 0777? Dovrebbe saltare a destra fuori di una vera e propria relazione di IDS.

Dal punto di vista del database, non è possibile rilevare direttamente il database viene modificato utilmente. Si dovrebbe fare un pg_dump dello schema ogni giorno in un file ( pg_dumpall -g e pg_dump -s , quindi diff che contro l'ultima hai consegnato e ancora una volta avvisare quando è cambiato. Se si riesce che questo bene, il contatto con il cliente si trasforma in "abbiamo notato è stato modificato sul server ... che cosa è che si sta cercando di realizzare con questo?", che ti fa apparire come se fossi davvero prestando attenzione a loro. Questo può trasformarsi in un'opportunità di vendita, e si può smettere giocherellare con le cose più semplicemente sul fatto che stai andando a prenderlo immediatamente.

L'altra cosa che si dovrebbe iniziare a fare immediatamente è installare più software di controllo di versione, come si può su ogni scatola cliente. Si dovrebbe essere in grado di accedere a ciascun sistema, eseguire lo strumento di stato / diff appropriato per l'installazione, e vedere cosa è cambiato. Get That mail a voi regolarmente troppo. Ancora una volta, questo funziona meglio se combinato con qualcosa che scarica lo schema come componente a quello che gestisce. Non abbastanza persone usano seri approcci di controllo versione sul codice che vive nel database.

Questo è il gruppo principale di approcci tecnici utili qui. Il resto di quello che hai è un problema di gestione di consulenza cliente classico che è molto più di un problema persone di un solo computer. Su con la vita, potrebbe essere peggio - FSM aiuto che se si dà loro l'accesso ODBC e THey scoprire possono scrivere le proprie query in Access o qualcosa di semplice come quello.