Businessplan für eine Online-Plattform. Größtes Problem: Zahlen

[Alexander (HH)]

Moin Moin!

Das ichs möglichst skalierbar erstellen muss war mir klar. Allerdings steh ich etwas ratlos da wobei ich darauf genau achten soll. Denn aufgebaut ist das Projekt auf PHP, MySQL, JS(Ajax),(X)HTML, XML.
Wobei wohl das Problem bei PHP/MySQL liegen wird.
Worauf muss ich bei PHP achten? Meine bisherigen Sachen liefen alle auf einem Server.

Oh, und ein vernünfiges Backup-Konzept, das binnen Stunden ein Restore vom "Bare Metal" erlaubt, sowohl für Produktiv- als auch für Entwicklungsserver, hast Du natürlich auch parat. Richtig?
[...]
Wirklich ein Konzept wurde allerdings noch nicht entwickelt.

Darf ich mal ganz böse sein?

Ich nehm mir einfach mal die Freiheit, denn ich kenne dieses Szenario nur zu gut.

* Du hast keine Ahnung von Softwareentwicklung.
* Du hast keine Ahnung von Systemadministration.
* Du hast keinen Plan, wie man eine Firma aufbaut.

Wie schätzt Du unter diesen Voraussetzungen ein, eine erfolgreiche Firma aufzubauen, die zwingend erfordert, sich mit SW-Entwicklung und Systemadministration auszukennen?

Du kannst Dir natürlich Know-How dazukaufen, das ist keine Schande. Nur wirst Du weder Admins noch Entwickler für lau bekommen, und ein Geschäftsführer arbeitet auch nicht für'n Appel und 'n Ei. D.h. Du wirst massiv Personalkosten haben oder den entsprechenden Leuten sehr viele Anteile am Unternehmen versprechen müssen. Für ein Startup ist das genauso tötlich wie ein ahnungsloser Chef. Alternativ kannst Du versuchen, die entsprechenden Dinge selbst zu lernen. Das geht nicht von heute auf morgen, und ganz ohne Erfahrungen in mindestens zwei der drei Problembereiche würde ich keine Firma gründen wollen.

So, jetzt wieder etwas freundlicher:

Wenn Du im Büro nicht tonnenweise Server aufstellen willst, sieh Dir mal VMWare an. Damit kannst Du auf einem einzelnen Server mehrere Maschinen simulieren, z.B. DB-Server, SVN-Server, Development-Server, Test-Server und Staging-Server. Die kleinste Version VMWare Server ist immer noch kostenlos zu haben und reicht für diese Zwecke vollkommen aus.

Du packst Deine gesamte Entwicklung, inklusive aller Scripts für den Rollout auf Test-, Staging- und Produktivserver, in eine Versionsverwaltung (z.B. Subversion, git, ...). Ein einziger Script-Aufruf exportiert den aktuellen Stand auf den Testserver, ein zweiter Script-Aufruf führt ein paar hundert bis ein paar Tausend Standard-Tests durch. Auf den Staging-Server kommt die getestete Version mit einem dritten Script-Aufruf, wenn dort alles problemlos läuft, bringt der vierte Script-Aufruf die selbe Version auf den Produktivserver. Auf GAR KEINEN FALL wird auf dem Produktivserver Code verändert oder gar herumdebuggt. Alle Server laufen mit exakt der selben Code-Basis (wobei natürlich Test und Staging "der Zeit voraus" sind) und mit exakt der selben Konfigrationsdatei, die Unterscheidung, welche Konfiguration ausgewählt wird, trifft ein einziges Stückchen Code z.B. anhand des Hostnamens oder anhand einer Marker-Datei irgendwo im Dateisystem (/etc/company/staging existiert nur auf dem Staging-Server, /etc/company/test existiert nur auf dem Test-Server, /etc/company/live existiert nur auf dem Produktiv-Server).

Zum Backup habe ich in der Vergangenheit öfter mal was gepostet. Deine Idee eines täglichen und eines monatlichen Backups ist schonmal gar nicht schlecht, aber noch lange nicht optimal. Einer meiner ehemaligen Arbeitgeber hat folgende Lösung benutzt:

Vier Sets von Bändern werden farblich markiert (rot, gelb, grün, blau), dabei liegen immer drei Sets im Banktresor bzw. im erstschlagsicheren Bunker (ja, das ist Overkill!), das vierte Set ist aktiv. Zu jedem Wochenbeginn wandert das aktive Set in den Tresor, das älteste Set kommt wieder aus dem Tresor raus und wird das neue aktive Set. Die Sets rotieren also wöchentlich. Jedes Set besteht aus einem Band pro Werktag plus einem Sonntagsband. Das Sonntagsband enthält ein vollständiges Backup, die anderen Bänder ein tägliches inkrementelles Backup.

Weder Bandlaufwerke noch Kassetten sind sonderlich billig, und gerade die Bandkassetten sind echte Verschleißteile. Diese Lösung ist für ein Startup in aller Regel also etwas zu teuer.

Für meinen Home-Server habe ich eine externe Festplatte (zur Zeit USB 2.0, die nächste wird E-SATA sein, weil USB zu langsam ist). Jede Nacht sichert ein cron-Job den GESAMTEN Serverinhalt auf die Festplatte, nachdem das jeweils älteste Backup von vor 10 Tagen gelöscht wurde. Der Trick: Hardlinks. Jede Dateiversion ist auf der Festplatte nur einmal gespeichert, aber erscheint durch Hardlinks in jedem Backup. Ändert sich die Datei, wird sie erneut gespeichert und nach und nach werden wieder Hardlinks auf diesen Stand angelegt. So kann ich 10 Backup-Generationen anlegen, brauche aber nur etwa 1,3x so viel Platz wie für ein Backup, nicht 10x so viel.

Dieses Verfahren hat aber gravierende Nachteile: Fällt die Backup-Platte aus, sind alle Backups weg. Und sollte das Server-Betriebssystem mal Amok laufen (durch Fehler oder Angriff), kann die Backup-Platte sehr leicht gelöscht werden, denn im Gegensatz zum Band kann das Backup-Medium nicht so leicht getauscht werden. Und es fehlt die räumliche Trennung. Schlägt ein Blitz ein oder beklaut mich ein Einbrecher, sind Maschine UND Backup weg.

Für ein Startup würde ich daher zwei bis drei identische Festplatten anschaffen, die täglich oder wenigstens wöchentlich rotiert und "off-site" in einem Bankschließfach gelagert werden.

Alexander