Je tiens à vous féliciter pour vos livrables. La couverture fonctionnelles a pratiquement été atteinte par toute les devopsteams.
Review générale
Ce chapitre regroupe les éléments que j'ai retrouvés chez plusieurs devopsteams. Plusieurs points mentionnés ici n'ont pas eu d'impact sur votre note de module, mais c'est ainsi que je vous donne, aussi, des pistes pour la suite.
Les systèmes générant des logs (dès qu'il y a des services) sont prolifiques. C'est une problématique que vous devez solutionner dès le début du projet. Mettre en place des rotations de logs est essentiel.
Schéma d'infrastructure.
Pensez à bien indiquer le sens de communication entre vos différentes couches. Dans le cas d'un firewall statefull ceci est essentiel.
Eviter de mentionner plusieurs fois la même information sur le schéma. Lors de la première mise à jour vous risquez des incohérences.
Sourcez vos documents. Mentionnez un fait, une valeur reprise d'un site et de ne pas mentionner la source et légalement plus que limite. Mais au-delà de cela, d'un point de vue ethique ne le fait pas. Nombreuses pages de vos wikis sont très bien sourcées, puis certains éléments plus du tout. Attention.
Versionnez vos documents. Rien de tel pour travailler en équipe avec les bons documents. Dans ce cas là je pense non seulement à votre schéma d'infrastucture, mais aussi à vos codes. Vous avez intégré dans votre wiki parfois des scripts, des templates d'email, des configurations d'agent. Ceci doit être dans le dépôt -code- (excepté le schéma).
Fonctionnalités
Comme son nom l'indique, ce chapite ne se concentre uniquement et que sur les fonctionnalités (démontrées en démo).
Note : si ne me mentionne rien, c'est que vous avez atteint l'objectif.
[x] Accès au dashboard
[x] Lister les hôtes
[x] Récupérer les métriques de base (CPU/RAM/DD)
[x] Superviser l'état de services
[x] Alerter les différents publiques
Le langage n'est pas adapté en fonction du flux.
[x] Agir de manière automatique sur les hôtes (uniquement pour une service hébergé sur le client Linux)
Clean infra
Ce chapitre a pour but d'évaluer la "propreté" de votre livrable.
[x] Etat des logs après un redémarrage
Une erreur est présente dans les logs après le redémarrage issue.
[x] Sécurité
Note : j'ai allégé ce critère. L'idée était de valoriser un fonctionnelment correcte en appliquant stricto sensu les règles de sécurité les plus restreints. Ceci demandait un temps d'analyse plus important que ne le permettait la démonstration. J'ai gardé uniquement le critère d'identification des ports et protocoel et leur mention dans le schéma. On validera cela ensemble une fois "dockerisé".
Transmissibilité
L'idée de prendre un projet et de le mettre à la poubelle m'aggace profondément. J'évalue donc la qualité de vos schémas, wiki et issues pour voir si une reprise de votre projet est envisageable. Ce qui tombe bien, vu que vous allez effectivement reprendre ce projet pour MAS en deuxième année.
[x] Schéma de l'infra
En plus du schéma livré en début de projet par mes soins, vous produisez deux schémas supplémentaires.
Certaines ports et protocoles ne sont pas mentionnés clairement (db ?).
[x] Choix de la solution
Votre produit n'offre qu'une version. Je comprends du coup la manque de justification.
Le choix de l'OS n'est pas contre par argumenté.
L'idée de ce livrable était de motiver vos choix et votre approche. Vous n'avez fait que remplir le template que j'ai livré, comme un formulaire. Dommage.
[x] Licence
Le type de licence est mentionné. Ok.
Dommage que vous ne mettiez pas en évidence que le manuel d'utilisation, lui, (émet des contraintes différentes)[https://www.zabbix.com/fr/license].
[x] Dimensionnement de l'infra
Vous ne justifiez pas. Aucun lien avec l'éditeur.
[x] Lien avec la documentation officielle
Pour les pages qui décrivent la mise en place, vous avez bien sourcés. Mais pour les documents plus généraux (comme le choix du produit) on se retrouve à devoir les retrouver soi-même.
La plus belle des docs, c'est les scripts. Bel effort. Mais attention, si vous livrez des premières version de scripts (qui ne font aucun check), mentionnez bien "for dev purpose only".
[x] Soin, niveau de finition de la documentation
Gros travail. Bravo.
Le fait d'avoir utiliser un second outil pour l'édition (Notion apparemment) supprime la notion d'auteur, ainsi on a l'impression qu'un seul membre à produit le contenu.
[x] Issues - référencement des disfonctionnements ou des fonctionnalités qui ne donnent pas satisfaction
La systèmatique de documenter dans les issues n'est pas encore acquise.
Vous documentez durant la review finale.
Votre évaluation
Note du projet : 5.00
Note personnelle
Dieperink Anthony : 5.50 (je tiens à valoriser votre rôle de leader dans le projet)
Introduction
Je tiens à vous féliciter pour vos livrables. La couverture fonctionnelles a pratiquement été atteinte par toute les devopsteams.
Review générale
Ce chapitre regroupe les éléments que j'ai retrouvés chez plusieurs devopsteams. Plusieurs points mentionnés ici n'ont pas eu d'impact sur votre note de module, mais c'est ainsi que je vous donne, aussi, des pistes pour la suite.
Fonctionnalités
Comme son nom l'indique, ce chapite ne se concentre uniquement et que sur les fonctionnalités (démontrées en démo).
Note : si ne me mentionne rien, c'est que vous avez atteint l'objectif.
[x] Accès au dashboard
[x] Lister les hôtes
[x] Récupérer les métriques de base (CPU/RAM/DD)
[x] Superviser l'état de services
[x] Alerter les différents publiques
Le langage n'est pas adapté en fonction du flux.
[x] Agir de manière automatique sur les hôtes (uniquement pour une service hébergé sur le client Linux)
Clean infra
Ce chapitre a pour but d'évaluer la "propreté" de votre livrable.
[x] Etat des logs après un redémarrage
Une erreur est présente dans les logs après le redémarrage issue.
[x] Sécurité Note : j'ai allégé ce critère. L'idée était de valoriser un fonctionnelment correcte en appliquant stricto sensu les règles de sécurité les plus restreints. Ceci demandait un temps d'analyse plus important que ne le permettait la démonstration. J'ai gardé uniquement le critère d'identification des ports et protocoel et leur mention dans le schéma. On validera cela ensemble une fois "dockerisé".
Transmissibilité
L'idée de prendre un projet et de le mettre à la poubelle m'aggace profondément. J'évalue donc la qualité de vos schémas, wiki et issues pour voir si une reprise de votre projet est envisageable. Ce qui tombe bien, vu que vous allez effectivement reprendre ce projet pour MAS en deuxième année.
[x] Schéma de l'infra
En plus du schéma livré en début de projet par mes soins, vous produisez deux schémas supplémentaires.
Certaines ports et protocoles ne sont pas mentionnés clairement (db ?).
[x] Choix de la solution
Votre produit n'offre qu'une version. Je comprends du coup la manque de justification.
Le choix de l'OS n'est pas contre par argumenté.
L'idée de ce livrable était de motiver vos choix et votre approche. Vous n'avez fait que remplir le template que j'ai livré, comme un formulaire. Dommage.
[x] Licence
Le type de licence est mentionné. Ok.
Dommage que vous ne mettiez pas en évidence que le manuel d'utilisation, lui, (émet des contraintes différentes)[https://www.zabbix.com/fr/license].
[x] Dimensionnement de l'infra
Vous ne justifiez pas. Aucun lien avec l'éditeur.
[x] Lien avec la documentation officielle
Pour les pages qui décrivent la mise en place, vous avez bien sourcés. Mais pour les documents plus généraux (comme le choix du produit) on se retrouve à devoir les retrouver soi-même.
La plus belle des docs, c'est les scripts. Bel effort. Mais attention, si vous livrez des premières version de scripts (qui ne font aucun check), mentionnez bien "for dev purpose only".
[x] Soin, niveau de finition de la documentation
Gros travail. Bravo.
Le fait d'avoir utiliser un second outil pour l'édition (Notion apparemment) supprime la notion d'auteur, ainsi on a l'impression qu'un seul membre à produit le contenu.
[x] Issues - référencement des disfonctionnements ou des fonctionnalités qui ne donnent pas satisfaction
La systèmatique de documenter dans les issues n'est pas encore acquise.
Vous documentez durant la review finale.
Votre évaluation