Sensible naming schemes for servers in trading environments

Sensible naming schemes are more than just pretty. They remove unnecessary operational risk.

DL360 Gen10 servers' hard disks spinning with HDD indicator lights

Who cares about hostnames?

Operational Risk Committees 🙂 Having a clear, predictable structure for server naming is an often-overlooked facet of scalable trading environments. Bad schemes could directly affect a firm’s P/L (for example, Knight Capital.)


  • 15 ASCII chars for hostname (excludes DNS labels that make up the FQDN – constraint exists for NetBIOS compliance)

Information we want to convey

  • the “stuff” that runs on it (kube, mysql)
  • the serial of the box (1, 2, …)
  • the location (ny4, ld4, …)
  • the stability (prod/uat)

My proposal

what stuff runs on this domain.enterprise

For example:

    (the first host in a k8s cluster in Foo’s internal network, in the LON site)
    (a DMZ box in Bar’s network, a subsidiary Foo acquired)
    (the 25th low-latency derivatives trading box in CME Aurora)

If a server could execute live trades, start its name with prod.

If a server should never trade, start its name with uat.

Add logic to your order management code to block any order from a server starting uat (plus log an alert) and only trade orders coming from prod.

Note: this may waste CPU cycles in ULL environments. Running dedicated layer 1 PROD and UAT networks is not a ridiculous idea.

DNS labels!

The nice thing with my scheme is that a human working inside the DMZ couldn’t accidentally reboot a core domain controller with Restart-Computer -force dc1-lon. It would restart the DMZ DC. They would need to explicitly parse

Too many DNS labels are bad. is not good. You either have to always specify FQDNs or complicate DHCP configurations with multiple search domains.

Bonus: software account names

In my lab, I use the following format:

  • no account name longer than 32 chars
  • must start with <letter>-:
    • l- for local accounts (e.g. in this post, l-gitlabci is an account that doesn’t exist in AD, just locally in /etc/shadow on the box)
    • d- for accounts that just exist to query directories like LDAP
    • q- for AD-based SQL Server logins
    • m- for accounts that just send e-mail
    • s- for anything else (the majority!)

All human usernames never have a hyphen, so I can easily distinguish a software account via regex matching if I wanted to. In reality, relying on OUs is better.