1. Pierre-Luc Dion pdion@cloudops.com
Infastructure documentations Flowchart,schemas and usefull informations
Pierre-Luc Dion

2. Overview Various type of schema
Usefull Information to provide (Ops perspective)
Flowchart (my favorite)
Share your opinions and ideas

3. Usefull tools for your docs
Text
Anything that is collaborative and can be shared and remain protected.
Google apps (doc, spreadsheet, sites)
wiki
docuwiki
confluence
mediawiki
sharepoint
Graphs
Tool you will be confortable to work with
Visio
Lucidchart
Confluence (plugin)
Lot of Visio shapes available:

4. Schemas Separate OSI layer in different schemas Layer 2 (link layer)
physical connectivity
Ethernet
Layer 3 (network layer)
IP, routing layer
Layer 4 (transport layer)
Flowchart, applications communications
WHY split into multiple shemas
help present L2 redundancy, physical connections
L3 provide routing not yet the application otherwise the schema is too dense
L4 express the application connection to provide requirement on the firewall or security gorups.
ease of expressing singlepoint of failure

5. Layer 2 example

6. Layer 3 example express network routing
firewall gateway have a single IP but two devices

7. Layer 4 example can easely identify application singlepoint of failure
Arrow express the direction of the TCP or UDP connection establiement

8. Valuable information in the flowChart
Each box is an application (ex: process, webserver, database, JVM,…)
OS type, IP, hostname
Application name/type
Listen port(s)
init script
path to log files
Arrow express connection initiation (not the direction of data)
helpful for troubleshooting and System Operation

9. event more… Hypervisor (it’s a VM/instance/Bare)
NFS share if it’s required by Apps
Backup: software connectivity and origin
Which system USER is use to execute the app
Automation system connectivity

10. Flowchart does not contain
SNMP
System admin (RDP, SSH, Telnet,…)
Unreleated to the application stack (system cron, system daemons)
NTP
Hypervisor tool (vmware tools, xentools,…)
Italic mean you could have them since it’s an application dependency

11. Tricks of the trade Build your own Visio Stencils (shapes)
Top to bottom mean from Insecure to Secure
Have a color coding for app boxes

12. When to Start the documentation?
Before the project begin
As you learn the application stack

13. Before the project start
Based on:
assumptions
Known applications that will be use
What it should look like
Will allow you to
Understand dependencies;firewall and connectivity
What need to be build as infrastructure

14. As you learn the system
Allow you to validate what you understand on the application stack.
Sometime it help existing team to better understand what they build and/or support

15. Enough
Time to see more examples…

16. C’est fini
Thank you
Questions/Comments?