問題描述
如何跟踪系統依賴關係？ (How to track System Dependencies?)
簡介
在我目前的組織中，我們有許多桌面應用程序和網絡應用程序在某個時候都相互影響。在維護舊應用程序或創建新應用程序時，很難嘗試記住哪個系統依賴於其他系統才能工作。我不是在談論諸如 DLL 和圖像之類的軟件依賴項，而是在談論整個系統，例如依賴於 HR 系統等的財務系統。
我的問題
跟踪整個系統如何依賴於另一個系統的最佳方法是哪一種？
答案可以是執行上述操作的方法、軟件包或文檔技術。
<
參考解法
方法 1:
I would say to clearly state that on your architecture design document. There are some good tools for this like Enterprise Architect. This tool allows you to create diagrams using the UML standard for describing these dependencies in a clear and visual way.
方法 2:
The best source of information is usually found in Config files. This typically has the connection strings, web service urls etc which will give a good idea on the external dependencies.
Another technique is by using profiling or tracing and applying filters, we can easily track any external calls. Most of the cases, the dependency is in the database layer, and checking for linked servers and tracking their dependencies can unearth lots of info.
I am not sure if there is any automatic way to get this info especially if the systems are on multiple platforms. Lot of manual work will be involved to document all that.
方法 3:
This is the kind of application we produce at Tideway Systems, and which many large organizations use for just this purpose. You can use the product to discover your estate, and use the modeling capabilities to describe your business apps (which typically consist of more than one piece of software and span servers).
It sounds like you qualify to use the free Community Edition of Foundation, which you can use on up to 30 servers ‑ just download it and check it out. Then let us know what you think please!
Disclaimer: I run the development group at Tideway. The product is very cool IMO, although I haven't written any of it myself directly :)
方法 4:
Turn off each machine one by one and see what breaks.. ;p
Seriously though, there is no simple answer to this question. With a collection of systems you could create a diagram showing the basic dependencies, but it wouldn't have a great deal of meaning unless you had an idea of what the dependency was. Usually your goal is to determine what you need to "revalidate" when you change another system, not which machines you can turn off at random. But that kind of information requires a large amount of detail and is hard to accumulate in the first place.
All this eventually ends up in a situation where you're systems are ahead of your automation. You'll never find a shrink wrapped automation tool that keeps up. On the other hand with so much detail necessary anything that can take care of half or even a third of the workload is going to be valuable.
方法 5:
This is a good question ‑‑ we struggle with this every time, it seems.
What we've tried to do over the last year or so is be "ruthless" on two things:
automation ‑‑ if you automate it and build/deploy often, then the automation process will tend to get things right most of the times (config settings, etc)
wiki, wiki, wiki ‑‑ we try to be hard‑core on keeping the team and project wiki up‑to‑date.
Curious to see other responses.
(by GateKiller、Jorge Ferreira、Gulzar Nazim、Allan Mertner、nedruod、DustinB)