Personally, I manage 3 production orgs (each with their own Sandboxes) + about a dozen dev orgs. It get's very tricky knowing what Metadata is in which org (since about half of the orgs pertain to one large project, new code isn't always deployed to every org, and often, classes are in various states of development among orgs).
For your tracking, I'd say, note:
- Org Name
- Org Type (Production, Sandbox, Full-Sandbox, Developer)
- Login credentials for the master-admin (username, password, and security token) so you can always access the metadata via API (e.g. Eclipse Salesforce IDE)
Text Area fields to track things like a
Code Updates, etc. (whatever you like)
- Some way to track Sandbox hierarchy: Say you have an org with many Sandboxes. It's a good practice to have only 1 sandbox, call it the "Master Sandbox" able to deploy change sets to the Production Org. The idea is to have the "Master Sandbox" be a facsimile of the Production Org (metadata-wise). That way any tests that pass in the "Master Sandbox" should pass in the Production.
- Maybe some URL fields for important links (e.g. files in chatter
Files, Visualforce pages)
You could also have a Child object(s) to store a description of any changes that were made that day, who made them, implications, etc.