Using Pass to save password securely. It requires GPG and keyes
gpg2 --gen-key
gpg --list-keys
gpg --list-keys #Note Pubkey
pub 2048R/0850D367 2020-11-09
uid Securepass-store pass@nobody.com
sub 2048R/677223F7 2020-11-09
#Initialise password store using GPG UID or Pub
pass init 2048R/0850D367
Password store initialized for 2048R/0850D367.
#Now Pass is ready to ass password
pass insert -n user1
Accuracy: Achieving 100% accuracy is not always practical and often very expensive/time-consuming. Each time you write a script/software, you must consider the level of accuracy required. Whatever may be the requirement always maintain a high level of accuracy.
Best Practices: Following industry-standard best practices always makes your code easy to read, identify mistakes, easy to modify, etc. Many codes are written to run for a long time and often have to revisit to make amendments. Following best practices makes it much easier to revisit and improve your code.
Consistency: This is the key to winning users' trust in your code. You only get one chance and if users lose confidence due to inconsistent results, it is very difficult to win them back. Go extra length to ensure your code produces a consistent result, and if it is not ready better not make it available than release incomplete script/software.
Documentation: It can be within the code itself and or externally. Every code should describe the purpose, and thought process at a high level. Programs should be intuitive and should contain help available to users.
Exception Handling: Every block code must have error checks to validate the result of each execution step and have an appropriate error message to clearly indicate the problem. Also at each stage of error check a decision has to be made on what action to be taken if a particular step fails.
Fault Tolerance: No service is 100% reliable, and should always have tolerance for failures. This is especially true when dealing with external services. There must be checks to detect faults and a plan to handle faults. For example, if there is a failure at and endpoint, you have to make sure your application does not keep sending requests or filling up resources on your own system which in turn can cause further failures.
Enterprise monitoring is a living breathing entity that requires constant evaluation and adjustments to produce the most reliable accurate results. Once defined it is not often reviewed and often edge case monitoring is added as new systems evolve. This often adds to false alerts, noise, and loss of trust in monitoring systems
An alert should be triggered only if it warrants definite action and has defined action to work on. When designing monitoring, people always get carried away with the number of metrics available to monitor and ofter end up generating a lot of noise. Yes good to have monitoring data to help with troubleshooting, but that does not mean alert!
Quote from SRE Book
"The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four."
Not all metrics require monitoring and even fewer require alerting.
There are often 2 areas to consider when it comes to defining monitoring.
The Four golden signals are especially suitable for defining monitoring for events that generate alerts. For example, a high CPU for a short period does not always warrant Alerting unless there is an impact on Latency/errors and/or reaching resource saturation.
Number of alerts for same incident should be minimal. For example when an underlying host fails, all metrics on that servers will fail too. There must be single alert for the host and rest of the checks should have dependency on it to have quality alerting.
Also major noise maker is repeat alert. Once an alert been acknowledged or being actioned, further repeat alerts only disrupts investigation and increases recovery time as Engineer will have to deal/change thought process to attend alert.
| Text Format | Foreground (text) color | Background color |
| 0: normal text | 30: Black | 40: Black |
| 1: bold | 31: Red | 41: Red |
| 4: Underlined text | 32: Green | 42: Green |
| 33: Yellow | 43: Yellow | |
| 34: Blue | 44: Blue | |
| 35: Purple | 45: Purple | |
| 36: Cyan | 46: Cyan | |
| 37: White | 47: White |
