Many things can be improved with small effort. Transparency brings s*itloads of good. If this site inspires even few others to share, it's already a good start.
One of the central themes at Futurice is transparency. We can't build the best workplace in the Finland by not being open and honest. It really counts.
Information shared here is relevant for employees and clients. For others, it might be interesting. And it shows a way to be a little bit more open.
Too many things are being done certain way just because "that's how it has always been done". That's not how we can improve our work, our results and our environment. It's important to experiment.
Site is powered by bootstrap, jQuery, python and php running on Amazon EC2. All data is stored on redis database, except binary files (network map). All redis keys have expiration time, and redis is configured with maxmemory directive. If key name is changed, redis cleans up automatically after a while. Almost everything is cached using redis for faster access - for example autogenerated graphs (using rrdtool) are stored in redis.
Services are monitored using Pingdom. In addition to Pingdom, we use Zabbix internally. Pingdom provides public information pages, but those are rather limited, so we are using API to fetch information to local copy (JSON files in redis). Tooltips are provided by Bootstrap plugin. If we are doing a good job with keeping our services up, we can be proud of it, and if not, we need to improve.
Traditionally monitoring and uptime information is secret, but we didn't find any reason to continue this tradition. Security can't depend on secret hostnames or other details, so releasing status information is not a problem. Actually, we are not using split-horizon DNS at all. But we restrict all access to important internal servers (for example LDAP) and services (user management and so on) with firewalls.
Network map generation is handled by Network weathermap. It's not actively maintained, but mature enough for our use - and we couldn't find anything better. Traffic data is collected using MRTG. Our internal server collects traffic data, generates image and posts it to this server. Data is not realtime, and doesn't include for example security related backup links or networks.
We had discussions about releasing network structure and services information - main argument against was that all additional information might have surprising effects when collected together. We tried to release as much as possible without giving out anything too specific - all you can see here is available using normal network scanning tools.
Our IT team uses RT for tracking incoming emails. RT API wasn't good enough (we are not fan of Perl), so currently small program runs queries directly to MySQL database, fetches information, calculates aggregates and posts resulting data to this server. No access is allowed other way around.
When Futurice was smaller, we had just mailing list, and all emails went to all three members of IT team. Nowadays that's not feasible anymore. We highly recommend taking ticket tracking system into use even in smaller organizations. Using ticket tracking system doesn't necessarily mean adding complex process to handling incoming emails.
Printer information is fetched using SNMP, processed with Python and pushed to this server. Fun fact: many printer drivers use SNMP to fetch information from printer, and printers have SNMP enabled, even when management console says it's not.
It's hard to know what printer works right now, or is there a need for ordering some printer supplies. We have few printers around our offices, because unfortunately not everything can be handled electronically. Even though printers are on 24/7, power saving mode saves electricity quite a bit.
We have 1-wire temperature sensor in the corner of the sauna, connected to Arduino with Ethernet extension. Then, small sketch running on Arduino serves temperature with telnet.
There's no good reason to have temperature sensor in the sauna - but from time to time it's nice and sometimes even useful.
This service is built on following blocks:
And using following tutorials/documents:
Backend (data collection and generation) for this service is built on following blocks:
There's no need to keep source code of this service secret. You need your own backend services and credentials, though. Many parts are quick first versions, and there's always better way to do it. Feel free to fork, make improvements and create pull request. We're more than happy to merge improvements and cleanups.
Also, deployed RT code, Pingdom code, EventSource, Sauna graph, and index.php are available for viewing. Everything - not necessarily currently running versions, though - is available at github repository.