Then make the public bastion host a VPN gateway so that the SSH bastion host can only be reached by SSH. This way, even if the first bastion host/VPN gateway appliance gets compromised, an attacker still needs a security flaw in the SSH bastion host.
Oh, and I forgot: regularly update your systems! Subscribe to various security mailing lists - this is the fastest way of learning about vulnerabilities.
And if you're running web apps: clearly separate the individual virtual hosts using either a full chroot solution or stuff like suexec/suphp from each other; same goes for the database users. Only grant necessary DB privileges (e.g. no need to give a webapp db user the GRANT capability in MySQL).
If you're dead paranoid like me, set up the application servers as VMWare (or other virtualization) servers, and for each webapp, create an own virtual machine. Then, link the VMs with an internal network and create a "bridge" server running nginx/apache/squid as reverse proxy (which can also serve as SSL terminator to avoid spreading HTTPS certificates over dozens of machines!). Maybe use special IDS software to detect/prevent common attacks like SQL injections. This way, if your web-app gets hacked, at least the attack won't easily spread to the other servers.
Simple reason: if the software stack of one of the hosts gets compromised (e.g. a 0day is found in OpenSSH), then the other bastion host cannot be compromised with the same exploit.
Regularly back up your whole server disk off-site, and if possible, on tape as well as on disks. This way you can, if a hacker compromises your system, at least follow his tracks and minimize data loss.
Strictly firewall your servers - nothing except ports 80/443 public-facing; use a "bastion host" for SSH logins and only allow public-key based authentication (if you can, use two-factor auth, e.g. with SMS-PIN or Google's authenticator service).
For databases, use only database engines with atomic read/write and disable the write-back cache (i.e. force the database to only give a OK to the program when the DB change was provenly committed to disk!).
Always protect SSH and other keys with strong passphrases so that in the event your server gets compromised, at least a hacker can't easily decrypt your data. Encrypt sensitive stuff in the databases (credit card data, personal identity information).
Strictly limit management access to the servers to few employees. Protect the hardware with features like auto-powerdown if the rack/the server case gets opened. Disable the remote management interfaces present in many servers. Disable the firewire and USB ports in the BIOS of the server and protect the BIOS config with a strong password to prevent stuff like Firewire DMA memory access.
Have a disaster management plan written on paper, which details who is responsible for which operations part and how he can be contacted in an emergency. Use a second datacenter for hosting a fully-redundant hot spare (or production, if the code allows). Do not exclusively rely on Cloudflare for protecting your servers from DDoS attacks; CF is a prime target for failures.
Keep the ops documentation current. Document everything, because you can always be hit by a bus, arrested by cops or injured or whatever.