UPDATED - 07/20/2016 - Tom J
- Teach the customer to fish - empower them, give them confidence, teach them how the system works.
- Determine what the customer needs are from the SA or ECAT perspective.
- Determine if the customer needs fit within the boundaries of the proposed solution.
- Ask the right SA or ECAT questions. Wrong questions will waste your time and the customer's time.
- Architect for the future. This will save valuable time and assist in the customer success and overall satisfaction.
- Be realistic. Take on the low hanging fruit first. Get the customer to 80% using existing rules. The other 20% will be for customized work.
- Not all hosts are equal - this seems obvious but I see this problem all the time. Customers should identify critical systems such as domain controllers, web servers, etc. Our job, to implement a solution that protects these vital systems from the other non-critical system.
- Deploy VLCs locally. Customers should not be pulling remote logs from across geographic locations - to avoid latency issues, excessive bandwidth usage, etc. Example, do not pull logs from Hawaii to New York over the WAN... deploy a VLC in Hawaii and pull the logs to the VLC then send from the Hawaii VLC to New York in one stream, not many streams.
- Size does matter - over engineer the solution when you can but keep the architecture simple and logical. The more complicated a solution becomes the more difficult it is to maintain it (KISS principal). Again, this translates into customer success and satisfaction.
- Be involved with the customer. As engineers we typically avoid the small talk and get to business. Start a light conversation with the customer to build rapport. You'll be amazed at what the customer will share with you regarding his/her environment and enable you to obtain a deeper understanding.
- Avoid making customer adjustments that only you know about, such as custom scripting that will impact the environment - this does not include monitoring and other general tasks such as cron. Work within the confines of the product... avoid "creative modifications" to circumvent a problem with the system because chances upgrades, service patches, etc may impact it negatively. Escalate the problem so engineering can fix it.
The observations above are my short list and some items may be a little controversial but my question is what are your best practices?