Foundations · Module 7
OSI model and diagnostics
Master troubleshooting tools and techniques using OSI layers, browser DevTools, command-line diagnostics, and TLS certificate inspection.
Previously
Operations
Run systems reliably in production with Google SRE principles, four golden signals, observability triad, and effective incident response.
This module
OSI model and diagnostics
Master troubleshooting tools and techniques using OSI layers, browser DevTools, command-line diagnostics, and TLS certificate inspection.
Next
The ilities framework
Evaluate systems across quality attributes including security, privacy, accessibility, performance, reliability, scalability, maintainability, and more.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
A shared network model gives teams a calm order for troubleshooting.
What you will be able to do
- 1 Explain osi model and diagnostics in your own words and apply it to a realistic scenario.
- 2 OSI thinking is useful when it helps you isolate problems with evidence and tests.
- 3 Check the assumption "Each step is testable" and explain what changes if it is false.
- 4 Check the assumption "Claims are written" and explain what changes if it is false.
Before you begin
- No previous technical background required
- Read the section explanation before using tools
Common ways people get this wrong
- Guessing. Guessing is slow. Tests are faster.
- Tool worship. Tools help, but the model makes output meaningful.
Master troubleshooting tools and techniques using OSI layers, browser DevTools, command-line diagnostics, and TLS certificate inspection.
A shared network model gives teams a calm order for troubleshooting. It replaces guesswork with evidence.
Mental model
Evidence-first diagnostics
OSI thinking is useful when it helps you isolate problems with evidence and tests.
-
1
Names
-
2
Routing
-
3
Transport
-
4
TLS
-
5
Application
Assumptions to keep in mind
- Each step is testable. If you can test each step, you can isolate faults quickly.
- Claims are written. Write the layer and the evidence. It keeps thinking calm.
Failure modes to notice
- Guessing. Guessing is slow. Tests are faster.
- Tool worship. Tools help, but the model makes output meaningful.
Check yourself
Quick check. OSI model and diagnostics
0 of 5 opened
Why check DNS and TLS early in a user facing outage
Because name resolution and certificate failures can make a service look down even when the app code is fine.
Scenario. A browser shows a certificate expiry error. What does that mean
TLS could not be established safely, usually because the certificate is expired, the hostname does not match, or the chain is broken.
What does traceroute help you understand
Where packets travel and where delays or drops appear along the path.
What is the difference between a 4xx and a 5xx
4xx is a client side error such as bad request or unauthorised. 5xx is a server side failure.
Why write evidence down during troubleshooting
It prevents guesswork, makes handover easier, and stops teams repeating the same checks under pressure.
Artefact and reflection
Artefact
A short module note with one key definition and one practical example
Reflection
Where in your work would explain osi model and diagnostics in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
Network fundamentals, browser DevTools, and command-line diagnostics