2. Enumeraț i uneltele esenț iale folosite în Devops.

Git
Jenkins
Selenium
Păpuș ă
Chef
Ansible
Nagios
Docker
Monit
ELK–Elasticsearch, Logstash, Kibana
Collectd/Colectează
Git(GitHub)

3. Care sunt operaț iunile de bază ale DevOps în ceea ce priveș te dezvoltarea ș i infrastructura?

Operaț iunile de bază ale DevOps

Dezvoltarea aplicaț iilor

Dezvoltarea codului
Acoperirea codului
Testare unitară
Ambalare
Implementare cu infrastructură
Provizionare
Configuraț ie
Orchestrare
Implementare

4. Care sunt avantajele DevOps din perspectiva Tehnică ș i de Afaceri?

Beneficii tehnice:

Livrarea software-ului este continuă.

Reduce complexitatea în probleme.
Abordare mai rapidă pentru a rezolva problemele
Forț a de muncă este redusă.

Beneficii pentru afaceri:

Rată înaltă de livrare a caracteristicilor sale

Mediile de operare stabile
Mai mult timp câș tigat pentru a adăuga valori.
Permiț ând un timp mai rapid de lansare a caracteristicilor

5. Domeniul de aplicare pentru SSH?

 SSH este un Shell Securizat care oferă utilizatorilor un mecanism sigur, criptat pentru a se conecta
în sisteme ș i transferă fiș iere.
Pentru a te deconecta de la o maș ină la distanț ă ș i a lucra în linia de comandă.
Pentru a asigura comunicaț ii criptate între două gazde pe o reț ea nesigură.

6. Care sunt domeniile în care se implementează DevOps?

Dezvoltarea producț iei

Crearea feedback-ului de producț ie ș i dezvoltarea acestuia
Dezvoltarea operaț iunilor IT

7. Listează metodologia agile a DevOps.

DevOps este un proces

Agile este acelaș i lucru cu DevOps.
Grupul separat pentru sunt cadru.
Este rezolvarea problemelor.
Dezvoltatori care gestionează producț ia
DevOps este managementul lansărilor condus de dezvoltare

8. Listează diferenț a majoră între Agile ș i DevOps.

Agil

Agile este despre dezvoltarea software-ului

Devops

DevOps se referă la implementarea ș i gestionarea software-ului.

2. DevOps nu înlocuie ș te Agile sau Lean. O face prin eliminarea risipei, îndepărtând
predări ș i simplificarea desfăș urărilor pentru a permite o viteză mai mare ș i mai continuă
implementări în PRODUCȚ IE.

9. Numeș te limbajul de scripting popular în DevOps.

Python
10. Cum este DevOps util pentru dezvoltatori?

Pentru a remedia eroarea ș i a implementa rapid noi funcț ii.

Oferă claritatea comunicării între membrii echipei.

11. Ce este Vagrant ș i care sunt utilizările sale.

Vagrant a folosit VirtualBox ca hypervisor pentru medii virtuale ș i în prezent

scenariul suportă de asemenea KVM. Maș ina virtuală bazată pe kernel
 Vagrant este un instrument care poate crea ș i gestiona medii pentru testare ș i dezvoltare
software.

Eș ti interesat să înveț i DevOps? Avem un curs cuprinzătorCursuri de Formare DevOpspentru

îț i oferă un avantaj în cariera ta.

12. Care sunt principalele diferenț e dintre sistemele de operare Linux ș i Unix?

Unix:

Aparț ine familiei sistemelor de operare multitasking ș i multiutilizator.

Acestea sunt folosite în principal în servere de internet ș i staț ii de lucru.
Este derivat în mod original din AT&T Unix, dezvoltat începând cu anii 1970 la Bell
Centrul de cercetare Labs de către Ken Thompson, Dennis Ritchie ș i alț ii.
Ambele sisteme de operare sunt open source, dar UNIX este relativ similar.
comparativ cu LINUX.

Linux:

Linux a fost probabil casa fiecărei limbaje de programare cunoscut de umanitate.

Acestea sunt utilizate pentru calculatoare personale.
LINUX este bazat pe nucleul sistemului de operare UNIX.

13. Cum ne putem asigura că noul serviciu este pregătit pentru produsele lansate?

Sistem de backup
Planuri de recuperare
Împărț irea încărcării
Monitorizare
Logare centralizată

14. Care sunt beneficiile NoSQL?

Model de date non-relaț ional ș i fără schemă

Latentă scăzută ș i performanț ă ridicată
Foarte scalabil

15. Care sunt adopț iile DevOps în industrie?

1. Utilizarea metodologiilor ș i proceselor agile ș i altor metode de dezvoltare.

2. Cererea pentru o rată crescută a produc ț iei eliberate din aplica ț ii ș i afaceri.
3. Disponibilitate largă a infrastructurii virtuale ș i cloud atât din surse interne, cât ș i externe
furnizori
4. Utilizarea crescută a centrelor de date, a automatizării ș i a instrumentelor de gestionare a configura ț iei;
5. Cre ș terea accentului pe automatizarea testării ș i metodele de integrare continuă;
6. Cele mai bune practici în probleme critice.
16. Care sunt avantajele unei baze de date NoSQL în comparaț ie cu RDBMS?

Avantajele sunt:

Există foarte pu ț in spa ț iu pentru ETL

2. Support is given for unstructured text
3. Schimbările sunt gestionate pe parcursul unei perioade de timp
4. Obiectivele principale sunt func ț ionalitatea.
5. Are capacitatea de a se scala orizontal
6. Se oferă suport pentru mai multe structuri de date.
7. Furnizorii pot fi ale ș i.

Oferiț i carierei dumneavoastră un mare impuls trecând prin programul nostruVideoclipuri de instruire DevOps!

17. Cele mai bune 10 abilităț i pe care o persoană ar trebui să le aibă pentru poziț ia de DevOps?

Excelent în administrarea sistemelor

Experienț ă de virtualizare
Abilităț i tehnice bune
Scriptare excelentă
Abilităț i de dezvoltare bune
Experienț ă în uneltele de automatizare Chef
Managementul oamenilor
Serviciul pentru clienț i
Operaț iuni Cloud în timp real
Cine se îngrijorează de cineva

18. Explicaț i cum este procesată sau executată implementarea 'Infrastructure as code' în
termeni de AWS.

În AWS,

Codul va fi în format JSON simplu.

Acest cod JSON este bine organizat în fiș iere numite template-uri.
Aceste ș abloane sunt desfăș urate pe AWS ș i apoi gestionate ca stive.
Serviciul Cloud Formation va ajuta în crearea, ș tergerea, actualizarea etc.
operaț iune în stivă.

19. Ce măsuri am luat pentru a gestiona controlul versiunilor?

Pentru a gestiona controlul versiunilor, publică-ț i codul pe SourceForge sau GitHub astfel încât toată lumea să poată să-l vizualizeze.
ș i cere spectatorilor să ofere sugestii pentru o îmbunătăț ire mai bună a acesteia.

20. Care sunt tipurile de cereri HTTP?

Tipurile de cereri Http sunt

OBȚ INE
 CAP
Pune
POST
PATCH
Ș terge
URMĂRIRE
CONECTEAZĂ
OPȚ IUNI

[Link]

Întrebări de bază
1)DevOps ! Cum ai putea să-l defineș ti în cuvintele tale?
Este o colaborare zilnică extrem de eficientă între dezvoltatorii de software ș i operaț iunile IT
inginerii de operaț iuni web pentru a produce un sistem funcț ional sau a lansa software.

O implementare devOps este în general aliniată cu metodologiile Agile unde

implementarea software-ului funcț ional în producț ie este, în general, cea mai mare prioritate. În Agile
în implementări, se pune accent pe oameni în loc de procese, astfel încât un inginer DevOps
trebuie să fie dispus să colaboreze foarte strâns cu echipele de dezvoltare Agile pentru a se asigura că acestea au
o mediu necesar pentru a susț ine funcț ii precum testarea automată, continuu
Integrare ș i livrare continuă. Într-o implementare tradiț ională, fără DevOps,
echipa de operaț iuni este adesea izolată de dezvoltatori, lucrând adesea sub un birou de ajutor
model sub acorduri generale de nivel de serviciu în care echipa de operaț iuni a sistemului tratează
dezvoltatori ca un client. Acesta este un model dovedit care, evident, poate funcț iona foarte bine,
dar într-un mediu DevOps, dezvoltarea ș i operaț iunile sunt eficientizate ș i barierele
între cele două grupuri nu ar trebui să existe.

2) De ce avem nevoie de DevOps?

Companiile se confruntă acum cu necesitatea de a livra aplicaț ii mai rapide ș i mai bune.
pentru a răspunde cerinț elor din ce în ce mai presante ale utilizatorilor conș tienț i de a reduce 'Timpul la'
Piaț ă. Devops ajută adesea ca desfăș urarea să aibă loc foarte repede.

Ce este dezvoltarea agilă ș i Scrum?

Dezvoltarea Agile utilizată ca o alternativă la practica de dezvoltare Waterfall. În Agile,
procesul de dezvoltare este mai iterativ ș i incremental, există mai mult testare ș i
feedback la fiecare etapă a dezvoltării, spre deosebire de doar ultima etapă în Waterfall.

Scrum este folosit pentru a gestiona dezvoltarea complexă a software-ului ș i a produselor, folosind abordări iterative ș i
practici incrementale. Scrum are trei roluri, adică proprietarul produsului, maestrul Scrum ș i echipa.

4)Putem considera DevOps ca o metodologie agilă?

Desigur! DevOps este o miș care pentru a reconcilia ș i sincroniza dezvoltarea ș i
production start through a set of good practices . Its emergence is motivated by a deep
schimbările cerinț elor afacerilor, care doresc să accelereze schimbările pentru a se menț ine mai aproape de
cerinț ele afacerii ș i ale clientului.

5) Care este datoria inginerului DevOps în ceea ce priveș te Agile

dezvoltare?
Inginerii DevOps lucrează foarte aproape de echipele de dezvoltare Agile pentru a se asigura că au
un mediu necesar pentru a susț ine funcț ii precum testarea automată, continuă
Integrare ș i livrare continuă. Inginerul DevOps trebuie să fie în contact constant cu
dezvoltatorii ș i fac toate părț ile necesare ale mediului să funcț ioneze perfect.

Întrebări tehnice
6)Ai lucrat cu containere?
Containerele sunt o formă de virtualizare uș oară, mai grea decât chroot, dar mai uș oară decât
hypervizori. Aceș tia oferă izolare între procese în timp ce folosesc acelaș i nucleu ca gazda
maș ină ș i funcț ionalitatea cgroups în cadrul nucleului. Dar formatele de containere diferă între ele
într-un mod în care unele oferă o experienț ă mai asemănătoare cu VM, în timp ce altele sunt contorizate
doar aplicaț ie.

Containerele LXC sunt cele mai asemănătoare cu VM-urile ș i cele mai grele, în timp ce Docker era folosit mai mult pentru
uș or ș i a fost iniț ial proiectat pentru un singur container de aplicaț ie. Dar în mai multe
versiunile recente Docker a introdus funcț ii de containerizare a întregii maș ini, aș a că acum
Docker poate fi folosit în ambele feluri. Există, de asemenea, rkt de la CoreOS ș i LXD de la Canonical,
care se bazează pe LXC.

Ce este Kubernetes? Explică.

Este un instrument extrem de scalabil pentru gestionarea containerelor, creat de Google. Este folosit
intern, pe desfăș urări mari ș i din acest motiv este poate cea mai bună opț iune pentru
utilizarea containerelor în producț ie. Suportă auto-repararea prin repornirea celor care nu răspund
containere, le ambalează într-un mod care necesită mai puț ine resurse ș i are multe alte
caracteristici excelente.

8) Care este funcț ia serverului CI (Integrare Continuă)?

Funcț ia serverului CI este de a integra continuu toate modificările care sunt făcute ș i angajate.
repository de către diferiț i dezvoltatori ș i verifică erorile de compilare. Trebuie să construiască codul
de mai multe ori pe zi, de preferinț ă după fiecare commit, astfel încât să poată detecta care commit a fost efectuat
ruperea dacă se întâmplă ruperea.

Notă: Alte instrumente CI populare ș i disponibile sunt Jenkins, TeamCity, CircleCI.

Hudson, Buildbot etc.

9) Ce este livrarea continuă?

Este practica de livrare a software-ului pentru testare imediat ce este construit de CI (Integrare Continuă)
Servere de integrare. Necesită utilizarea intensă a sistemului de control al versiunilor, aș adar întotdeauna
disponibil pentru dezvoltatori ș i testerii deopotrivă.

Ce este Vagrant ș i la ce se foloseș te?

Vagrant este un instrument care poate crea ș i gestiona medii virtualizate (sau containerizate)
pentru testarea ș i dezvoltarea software-ului. La început, Vagrant a folosit VirtualBox ca hipervizor
pentru medii virtuale, dar acum suportă ș i KVM.

11) Ai folosit vreodată un limbaj de scripting?

Cât priveș te limbajele de scriptare, cu cât sunt mai simple, cu atât mai bine. De fapt, limbajul în sine nu este la fel de
importante ca înț elegerea modelelor de design ș i paradigmelor de dezvoltare, cum ar fi
programare procedurală, orientată pe obiect sau funcț ională.

În prezent, există mai multe limbaje de scripting disponibile, aș a că întrebarea care apare este: care este
cea mai potrivită limbă pentru abordarea DevOps? Pur ș i simplu totul, depinde de
contextul proiectului ș i uneltele utilizate, de exemplu, dacă s-a folosit Ansible, este bine să fie
cunoș tinț e în Python ș i dacă este pentru Chef, este pe Ruby.

12) Care este rolul unui instrument de gestionare a configuraț iei în

devops?
Automatizarea joacă un rol esenț ial în gestionarea configuraț iei serverelor. În acest scop
folosim instrumente de gestionare a configurării, ele stochează informaț ii despre versiuni ș i construcț ii ale software-ului ș i

testware ș i oferirea trasabilităț ii între software ș i testware.

13) Care este scopul instrumentelor CM ș i pe care le aveț i?

folosit?
Scopul uneltelor de gestionare a configuraț iei este de a automatiza implementarea ș i configurarea
de software pe un număr mare de servere. Cele mai multe instrumente de gestionare a configuraț iei folosesc de obicei arhitectura agent.
ceea ce înseamnă că fiecare maș ină gestionată trebuie să aibă agent instalat. Preferatul meu
un instrument este acela care foloseș te o arhitectură fără agent - Ansible. Necesită doar SSH ș i Python.
Ș i dacă modulul brut este utilizat, nici măcar Python nu este necesar pentru că poate rula bash brut.
comenzi. Alte instrumente CM populare ș i disponibile sunt Puppet, Chef, SaltStack.

14) Ce este OpenStack?

OpenStack este adesea numit Sistem de Operare Cloud ș i asta nu este departe de adevăr. Este
mediu complet pentru implementarea IaaS care îț i oferă posibilitatea de a face
un nor propriu similar cu AWS. Este foarte modular ș i constă din multe sub-proiecte, astfel încât să
poț i alege ș i selecta funcț ionalităț ile de care ai nevoie. Distribuț iile OpenStack sunt disponibile
de la Red Hat, Mirantis, HPE, Oracle, Canonical ș i mulț i alț ii. Este complet deschis
proiect sursă, dar unii furnizori realizează distribuț ii proprietare.

15) Clasificaț i platformele de cloud într-o categorie?

Software-ul de calcul în cloud poate fi clasificat ca Software ca Serviciu sau SaaS,

Infrastructura ca serviciu sau IaaS ș i platforma ca serviciu sau PaaS.

SaaS este un software care rulează pe reț ea pe un server la distanț ă ș i are doar utilizator.
interfaț a expusă utilizatorilor, de obicei în browserul web. De exemplu [Link].

Infrastructura ca serviciu este un mediu cloud care expune VM utilizatorului pentru a fi utilizat ca întreg.
OS sau container unde ai putea instala orice ai instala pe serverul tău.
Un exemplu în acest sens ar fi OpenStack, AWS, Eucalyptus.
PaaS le permite utilizatorilor să îș i desfăș oare propria aplicaț ie pe platforma preinstalată, de obicei
cadru al serverului de aplicaț ii ș i suită de unelte pentru dezvoltatori. Exemple pentru aceasta ar fi
OpenShHeroku.

16) Care sunt cele mai uș oare moduri de a construi un mic nor?
VMfest este una dintre opț iunile pentru crearea unui cloud IaaS din VM-uri VirtualBox în niciunul
timp. Dacă doriț i un PaaS uș or, există Dokku, care este practic un script bash care
transformă containerele Dokku în PaaS.

17) Ce este AWS (Amazon Web Services)? Ai avut ocazia să ...

lucrează cu instrumentele Amazon?

AWS oferă un set de servicii flexibile concepute pentru a permite companiilor să creeze ș i
livraț i produse cu o viteză ș i fiabilitate mai mari folosind AWS ș i practici DevOps.
Aceste servicii simplifică punerea în funcț iune ș i gestionarea infrastructurii, codul aplicaț iei
implementare, proces de eliberare automată a software-ului ș i monitorizarea aplicaț iei ș i
performanț a infrastructurii. Amazon a folosit instrumente precum AWS CodeCommit, AWS
CodeDeploy, AWS CodePipeline etc, care ajută la simplificarea devops-ului.

Ce este EC2?
Amazon EC2 Container Service (ECS) este un serviciu de gestionare a containerelor foarte scalabil
ș i performanț ă ridicată care susț ine containerele Docker ș i îț i permite să rulezi cu uș urinț ă
aplicaț ii pe un cluster gestionat de instanț e Amazon EC2.

Serviciul EC2 este inseparabil de conceptul de Imagine a Maș inii Amazon - AMI.
Mai este într-adevăr imaginea unei maș ini virtuale care va fi executată. EC2 bazat pe
Virtualizarea XEN, de aceea este destul de uș or să mutaț i serverele XEN pe EC2.

19) Găsiț i vreo avantaje în utilizarea unei baze de date NoSQL faț ă de
RDBMS?
Aplicaț iile web tipice sunt construite cu o arhitectură în trei niveluri. Pentru a suporta încărcătura, mai multe
Serverele web sunt pur ș i simplu adăugate în spatele unui echilibrator de sarcină pentru a susț ine mai mulț i utilizatori. Capacitatea
scalarea în sus este un principiu cheie în lumea cloud computing-ului, din ce în ce mai important
în care instanț ele VM pot fi adăugate sau eliminate cu uș urinț ă pentru a răspunde cererii.

Cu toate acestea, când vine vorba de stratul de date, bazele de date relaț ionale (RDBMS) nu permit
o trecere la scala simplă ș i nu oferă un model de date flexibil. Gestionează mai mult
utilizatorii înseamnă adăugarea de servere mai multe ș i serverele mari sunt foarte complexe, proprietarii ș i
disproporț ionat de scump, în contrast cu hardware-ul de low-cost, „comercial”
hardware", arhitecturi în cloud. Organizaț iile încep să observe performanț a
probleme cu bazele lor de date relaț ionale pentru aplicaț ii existente sau noi. Mai ales pe măsură ce
numărul utilizatorilor creș te, ei îș i dau seama de necesitatea unei baze mai rapide ș i mai flexibile. Acest
este timpul să înceapă să evalueze ș i să adopte baze de date NoSQL ca în aplicaț iile lor web.
20) Care sunt principalele dificultăț i de migrare de la SQL la NoSQL?

Fiecare înregistrare într-o bază de date relaț ională conform unei scheme - cu un număr fix de câmpuri
(coloane) fiecare având un obiect specificat ș i un tip de date. Fiecare înregistrare este la fel. The
datele sunt denormalizate în mai multe tabele. Avantajul este că există mai puț ine date duplicat
în baza de date. Dezavantajul este că o schimbare în model înseamnă efectuarea mai multor
„ALTER TABLE” care necesită blocarea costisitoare a mai multor tabele simultan pentru a asigura că
schimbarea nu lasă baza de date într-o stare inconsistentă.

Cu datele din baze de date, pe de altă parte, fiecare document poate avea un conț inut complet diferit
structură din alte documente. Nu este necesară gestionarea suplimentară a bazei de date pentru
gestionaț i modificările în scheme.

21) Care sunt beneficiile bazelor de date NoSQL de tip Document?

Avantajele principale ale bazelor de date de tip document sunt următoarele:

model de date flexibil datele pot fi introduse fără un schema definită ș i formatul de
datele care sunt inserate pot fi schimbate în orice moment, oferind o flexibilitate extremă, care
în cele din urmă oferă o agilitate semnificativă afacerii
Consistent , high-performance Advanced NoSQL database technologies are putting
cache datele, transparent, în memoria sistemului; un comportament care este complet
transparenț i pentru dezvoltator ș i echipa responsabilă de operaț iuni.
Unele baze de date NoSQL cu scalabilitate uș oară propagă automat datele între
servere, fără a necesita aplicaț ii de participare. Serverele pot fi adăugate ș i eliminate
fără întrerupere a aplicaț iilor, cu date ș i I/O distribuite pe mai multe
servere.

22) Care sunt principalele avantaje ale Git faț ă de CVS?

Cel mai mare avantaj este că Git este distribuit, în timp ce CVS este centralizat. Schimbările în CVS
sunt pe fiș ier, în timp ce modificările (commit-urile) în Git se referă întotdeauna la întregul proiect. Git
oferă mult mai multe instrumente decât CVS.

23) Diferenț a dintre containere ș i maș ini virtuale?

Fiecare instanț iere VM necesită pornirea unui sistem de operare complet. VMs consumă multe resurse de sistem.
Acest lucru se adună rapid la o mulț ime de RAM ș i cicluri CPU. Gazda containerului foloseș te procesul
ș i caracteristicile de izolare a sistemului de fiș iere ale nucleului linux.

Ce este CoreOS ș i care sunt alternativele?

CoreOS este o distribuț ie Linux simplificată destinată rulării containerelor, în principal cu acesta
format rkt propriu, dar ș i altele sunt suportate. A fost iniț ial bazat pe ChromeOS ș i
a susț inut Docker. Alternativele la acesta sunt snappy-ul ubuntu de la canonical sau red hat
gazda atomică Enterprise Linux. Desigur, containerele pot fi rulate ș i pe Linux obiș nuit.
sistem.

Ce este Kickstart?
Este o modalitate de a instala sisteme bazate pe Red Hat într-un mod automat. În timpul instalării manuale
proces, instalatorul Anaconda creează fiș ierul [Link] care poate fi folosit apoi
cu instrumentul system-config-kickstart pentru a instala aceeaș i configuraț ie automat pe mai multe
sisteme.

26) Care sunt uneltele pentru monitorizarea reț elelor? Enumeraț i câteva.

De exemplu, Nagios, Icinga 2, OpenNMS, Splunk ș i Wireshark. Aceste instrumente sunt folosite
pentru a monitoriza traficul de reț ea, calitatea reț elei ș i a detecta problemele de reț ea chiar înainte de
ele apar. Dintre cele listate, doar Splunk este proprietar, celelalte sunt open source.

27)What is Juju ?
Juju este un instrument de orchestrare, în principal pentru Ubuntu, pentru gestionare, provisionare ș i
configurare pe sistemele Ubuntu. A fost scris iniț ial în Python ș i de atunci a fost
rescris în Go.

28) Dă-mi exemple de cum ai gestiona proiectele?

Ca inginer DevOps, aș demonstra o înț elegere clară a proiectului DevOps
tactici de management ș i de asemenea, lucrăm cu echipe pentru a stabili obiective, a optimiza fluxul de lucru,
menț ine domeniul, cercetează ș i introdu noi instrumente sau cadre, traduce cerinț ele
în fluxul de lucru ș i urmărire. Aș recurge la CI, gestionarea lansărilor ș i alte unelte pentru a
menț ine proiectele interdisciplinare pe drumul cel bun.

29) Ce sunt întâlnirile post mortem?

Este o întâlnire în care discutăm ce a mers prost ș i ce paș i ar trebui să fie urmaț i pentru ca
eș ecul nu se întâmplă din nou. Întâlnirile post-mortem nu sunt despre a găsi pe cineva de vină
blamaț i, ei sunt pentru a preveni reapariț ia întreruperilor ș i pentru a planifica redesignul
infrastructură astfel încât timpul de nefuncț ionare să poată fi minimizat. Este vorba despre a învăț a din greș eli.

Ce ș tiț i despre modelul serverless?

Serverless se referă la un model în care existenț a serverelor este ascunsă de dezvoltatori.
înseamnă că nu mai trebuie să te ocupi de capacitate, desfăș urări, scalare ș i toleranț ă la erori
ș i OS. Acesta va reduce esenț ial eforturile de întreț inere ș i va permite dezvoltatorilor să reacț ioneze rapid
focus on developing codes.

Exemple sunt Amazon AWS Lambda ș i platforma fără server Auth0.

Exemplu Devops: Distribuirea aplicaț iilor cu

Ansible
Ansible este o soluț ie uș oară ș i extensibilă pentru automatizarea aplicaț iei tale
provisioning. Ansible has no dependencies other than Python and SSH. It doesn’t require
niciun agent să fie configurat pe gazdele remote ș i nu lasă urme după ce rulează
nici. Permite să simplificăm semnificativ operaț iunile noastre prin crearea de YAML uș or
playbook-uri bazate. Este bun pentru automatizarea configuraț iei, desfăș urări ș i orchestrare.

Componente ale Ansible

Playbooks: Playbook-urile Ansible sunt o modalitate de a trimite comenzi către computerele de la distanț ă într-un
într-un mod scriptat. În loc să foloseș ti comenzile Ansible individual pentru a configura de la distanț ă
computere din linia de comandă, poț i configura întregi medii complexe prin
trecerea unui script către unul sau mai multe sisteme.

Playbook-urile Ansible sunt scrise în formatul de serializare a datelor YAML. Dacă nu ș tii
ce este un format de serializare a datelor, gândeș te-te la el ca la o modalitate de a traduce datele programatice
structură (liste, vectori, dicț ionare, etc.) într-un format care poate fi uș or stocat pe disc.
Fiș ierul poate fi folosit pentru a recrea structura la un moment ulterior. JSON este altul
format de serializare a datelor popular, dar YAML este mult mai uș or de citit.

Să ne uităm la un playbook de bază care ne permite să instalăm o aplicaț ie web (nginx) într-un
mai mulț i gazde :

hosts: webservers
tasks:
- name: Installs nginx web server
apt: pkg=nginx stare=instalată actualizare_cache=adevărat
notify:
- porneș te nginx
handlers:
- name: start nginx
service: name=nginx state=started
Fiș ierul hosts :(prin default sub /etc/ansible/hosts) acesta este fiș ierul Inventar Ansible, ș i
stochează gazdele ș i asocierea lor cu grupurile de gazde (servere web, baze de date etc.)

[webservers] [Link]
exemplu de stabilire a unui inventar de gazde prin adresă IP.
de asemenea, demonstrează cum să setaț i variabile pe fiecare gazdă.
[repository_servers] example-repository
#exemplu de setare a unui gazd prin numele gazdei. Necesită căutare locală în /etc/hosts
# sau DNS.
[dbservers] db01
Cheia SSH: Pentru prima rulare, va trebui să îi spunem lui ansible parolele SSH ș i Sudo.
because one of the thing that the common role does is to configure passwordless sudo,
ș i să implementeze o cheie SSH. Aș adar, în acest caz, ansible poate executa comenzile playbook-ului în
nodiile remote (gazdele) ș i implementaț i aplicaț ia web nginx.

1. Cum funcț ionează HTTP?

Protocolul HTTP funcționează într-un model client-server, la fel ca majoritatea celorlalte protocoale. Un browser web
Ceea ce inițiază o solicitare se numește client și un software de server web care răspunde la
această solicitare se numește server. Consorțiul World Wide Web și Task-ul de Inginerie a Internetului
Forțele sunt două spițe importante în standardizarea protocolului HTTP. HTTP permite
îmbunătățirea cererii și răspunsului său cu ajutorul intermediarilor, de exemplu, o poartă, un
proxy sau un tunel. Resursele care pot fi solicitate folosind protocolul HTTP sunt realizate
disponibil folosind un anumit tip de URI (Identificator Uniform de Resurse) numit URL (Locație Uniformă de Resurse)
Locator). TCP (Protocolul de Control al Transmiterii) este folosit pentru a stabili o conexiune cu aplicația
portul 80 folosit de HTTP.
2. Explicaț i înț elegerea ș i experienț a dumneavoastră atât în ceea ce priveș te dezvoltarea software-ului, cât ș i în
partea de operaț iuni tehnice a unei organizaț ii pentru care ai lucrat în trecut.
Inginerii DevOps lucrează aproape întotdeauna într-un mediu online critic pentru afaceri, 24/7. Am fost
adaptabil la îndatoriri de disponibilitate și capabil să preia responsabilitatea în timp real, pe un sistem activ. Am reușit
procese automatizate pentru a susține implementările continue de software. Am experiență cu
cloud-uri publice/private, instrumente precum Chef sau Puppet, scripting și automatizare cu instrumente precum Python
PHP și o experiență în Agile.
3. Discută despre experienț a ta în construirea de punț i între IT Ops, QA ș i dezvoltare.
DevOps se concentrează pe comunicarea și colaborarea eficientă. Am putut să mă ocup de
probleme de producție din partea dezvoltării și operațiunilor, navigând eficient între cele două domenii.
Sunt mai puțin interesat de găsirea vinovatului sau de a juca rolul de erou decât de a mă asigura că toate elementele în mișcare
părțile se reunesc.
4. Ce tipuri de teste sunt necesare?
Echipele de software vor căuta adesea calea „cu vreme bună” către finalizarea sistemului; adică, ele încep
dintr-o presupunere că software-ul va funcționa de obicei și va eșua doar ocazional. Cred că este important să practic
programare defensivă într-un mod pragmatic, ceea ce înseamnă adesea presupunerea că codul va eșua și
planificarea pentru aceste eșecuri. Încerc să încorporez strategia de teste de unitate, utilizarea unor structuri de testare, încărcare timpurie
testare; simulare de rețea, testare A/B și testare multivariată etc.
5. Dă-mi un exemplu de cum ai gestiona proiectele?
Ca profesionist cu responsabilități de conducere, aș demonstra o înțelegere clară a
Tactici de management al proiectelor DevOps și, de asemenea, colaborarea cu echipele pentru a stabili obiective, a eficientiza
flux de lucru, menține domeniul, cercetează și introdu noi instrumente sau cadre, traduce cerințele
în fluxul de lucru și urmărire. Aș recurge la CI, gestionarea lansărilor și alte instrumente pentru a menține
proiecte interdisciplinare pe drumul cel bun.
6. Care este obiectivul tău profesional în rolul de inginer DevOps?
Pasiunea mea este să sparg barierele și să construiesc și să îmbunătățesc procesele, astfel încât
echipele de inginerie și operațiuni lucrează mai bine și mai inteligent. De aceea îmi place DevOps. Este un
o oportunitate de a fi implicat în întregul sistem de livrare de la început până la sfârșit.
7. Cum ai face software-ul să fie implementabil?
Capacitatea de a scrie scripturi pentru instalarea și reconfigurarea sistemelor software este esențială pentru
schimbare controlată și automatizată. Deși există o tendință în creștere pentru ca noul software să permită
acestea, sistemele și produsele mai vechi suferă din cauza presupunerii că modificările vor fi rare și
minor, și astfel face modificările automatizate dificil de realizat. Ca profesionist care apreciază nevoia de
expune configurarea și setările într-un mod accesibil automatizării, voi lucra cu concepte
ca Inversarea Controlului (IoC) și Injectarea Dependențelor, instalare scriptată, cadre de testare,
separarea preocupărilor, unelte de linie de comandă și infrastructură ca cod.
8. Care este cel mai important lucru pe care DevOps ajută să-l facă?
Cel mai important lucru pe care DevOps îl ajută să-l facă este să aducă modificările în producție cât mai repede posibil.
posibil în timp ce se minimizează riscurile în asigurarea calității software-ului și conformitate. Aceasta este principalul
obișnuit al DevOps-ului. Cu toate acestea, există multe alte efecte secundare pozitive ale DevOps-ului. De exemplu,
comunicare mai clară și relații de lucru mai bune între echipe, ceea ce creează un mediu mai puțin
mediu de lucru stresant.
9. Ce limbaje de scripting credeț i că sunt cele mai importante pentru un inginer DevOps?
În ceea ce privește limbajele de scripting, cu cât sunt mai simple, cu atât sunt mai bune. De fapt, limbajul în sine nu este atât de important.
ca înțelegerea modelelor de design și a paradigmelor de dezvoltare precum cele procedurale, orientate pe obiect,
sau programare funcțională.
10. Cum te aș tepț i să fii necesar să faci mai multe sarcini deodată ca profesionist DevOps?
Cred că voi fi așteptat să:
Concentrați-vă atenția pe bridgerea decalajelor de comunicare între echipele de Dezvoltare și Operațiuni.
2. Understand system design from an architect’s perspective, software development from a
perspectiva dezvoltatorului, operațiuni și infrastructură din perspectiva unui sistem experimentat
Administrator.
3. Executa – a fi capabil să faci efectiv ceea ce trebuie făcut.
11. Ce testare este necesară pentru a asigura că un nou serviciu este pregătit pentru producț ie?
DevOps se concentrează pe testarea continuă pe parcursul procesului, începând cu dezvoltarea până la
production. Everyone shares the testing responsibility. This ensures that developers are delivering
cod care nu are erori și este de calitate înaltă, și ajută pe toată lumea să valorifice
timpul cel mai eficient.
12. Ce este un PTR în DNS?
Înregistrările pointer sunt folosite pentru a mapa o interfață de rețea (IP) la un nume de gazdă. Acestea sunt utilizate în principal
pentru DNS invers. DNS invers este configurat foarte similar cu modul în care este configurat DNS-ul normal (direct). Atunci când
tu delegi forward-ul DNS, proprietarul domeniului spune registrarului să permită domeniului tău să folosească
servere de nume specifice.
13. Descrie authentication cu două factori?
Autentificarea în doi pași este un proces de securitate în care utilizatorul oferă două metode de identificare.
din categorii separate de acreditive; unul este de obicei un token fizic, cum ar fi un card, și
cealaltă este de obicei ceva memorat, cum ar fi un cod de securitate.
14. Spune-ne despre uneltele CI cu care eș ti familiarizat?
Premisa CI este de a obține feedback cât mai devreme posibil, deoarece cu cât primești feedback mai devreme,
lucruri mai puține costă să fie reparate. Instrumentele open source populare includ Hudson, Jenkins, CruiseControl și
[Link]. Instrumentele comerciale includ Go de la ThoughtWorks, Anthill Pro de la Urbancode,
Jetbrains’ Team City și Microsoft’s Team Foundation Server.
15. Care sunt avantajele bazei de date NoSQL faț ă de RDBMS?
Avantajele sunt:
1. Necesitate mai mică pentru ETL

2. Suport pentru text necontrolat

3. Capacitatea de a gestiona schimbarea în timp
4. Lățimea funcționalității
5. Capacitatea de a scala orizontal
6. Suport pentru multiple structuri de date
7. Alegerea furnizorilor
16. Ce este un înregistrare MX în DNS?
MX-urile sunt înregistrări de schimb de e-mail utilizate pentru a determina prioritatea serverelor de e-mail pentru un
domeniu. Cel mai scăzut server de email cu prioritate este prima destinație pentru email. Dacă serverul de email cu prioritate cea mai scăzută
serverul este indisponibil, emailul va fi trimis către serverele de email cu prioritate superioară.
17. Care este diferenț a dintre RAID 0 ș i RAID 1?
RAID 1 oferă redundanță prin mirroring, adică, datele sunt scrise identic pe două unități. RAID 0
nu oferă redundanță și folosește în schimb striping, adică datele sunt împărțite pe toate unitățile. Asta înseamnă
RAID 0 nu oferă nicio toleranță la erori; dacă oricare dintre unitățile constituente eșuează, unitatea RAID eșuează.
18. Cum te-ai pregăti pentru o migraț ie?
Sfaturi pentru a răspunde: Această întrebare evaluează experiența ta în proiecte reale, cu toate neplăcerile.
și complexitatea pe care o aduc. Includeți termeni precum cut-over, repetiții generale, roll-back și roll-forward,
Soluții DNS, comutatoare de caracteristici, ramificare prin abstractizare și automatizare în răspunsul tău. Dezvoltare
sistemele greenfield cu puțină sau deloc tehnologie existentă în loc sunt întotdeauna mai ușor de gestionat decât a avea de-a face
cu componente și configurații legate de moștenire. Ca și candidat, dacă apreciezi că orice lucru interesant
sistemul de software va fi, în efect, sub o migrație constantă, vei părea potrivit pentru rol.
19. Care este backgroundul tău în sisteme?
Sfaturi pentru a răspunde: Unele locuri de muncă DevOps necesită cunoștințe extinse despre sisteme, inclusiv servere
clustering și sisteme cu mare concurență. Ca inginer DevOps, trebuie să analizezi sistemul
capabilități și implementarea de upgrade-uri pentru eficiență, scalabilitate și stabilitate, sau reziliență. Este
se recomandă să aveți o cunoaștere solidă a sistemelor de operare și a tehnologiilor de suport, cum ar fi rețeaua
securitate, rețele private virtuale și configurarea serverului proxy.
DevOps se bazează pe virtualizare pentru provisionarea rapidă a sarcinilor de lucru și alocarea resurselor de calcul pentru
VM-uri noi pentru a susține următoarea desfășurare, așa că este util să avem cunoștințe aprofundate despre cele populare
hypervizori. Acest lucru ar trebui să includă în mod ideal tactici de backup, migrare și gestionare a ciclului de viață pentru
protect, optimize and eventually recover computing resources. Some environments may emphasize
dezvoltare de software microservicii adaptată pentru containere virtuale. Expertiza în operațiuni este obligatorie
includ o cunoaștere extensivă a instrumentelor de gestionare a sistemelor, cum ar fi Microsoft System Center, Puppet,
Nagios și Chef. Locurile de muncă în DevOps cu un accent pe operațiuni necesită rezolvarea detaliată a problemelor,
abilități de depanare și analitice.
20. Cu ce instrumente DevOps ai lucrat?
Sfaturi pentru a răspunde: instrumente de gestionare a configurației software și de construire/lansare (controlul versiunilor)
inclusiv Apache Subversion, Mercurial, Fossil și altele, ajută la documentarea cererilor de modificare.
Developers can more easily follow the company’s best practices and policies while software
schimbări.
Instrumentele de integrare continuă (CI), cum ar fi Rational Build Forge, Jenkins și Semaphore, combină toate
dezvoltatorii copiază codul funcțional într-o versiune centrală. Aceste unelte sunt importante pentru proiecte mai mari
grupuri în care echipe de dezvoltatori lucrează simultan la aceeași bază de cod. Experții QA folosesc
analizatori de coduri pentru a testa software-ul pentru erori, securitate și performanță. Dacă ai folosit Fortify Static de la HP
Analizator de cod, discută despre cum a identificat vulnerabilitățile de securitate în limbajele de programare. De asemenea, vorbește despre
despre instrumente precum CodeSonar de la GrammaTech pe care le-ați folosit pentru a identifica scurgeri de memorie, subrunduri de tampon
și alte defecte pentru codul C/C++ și Java. Este esențial să aveți o stăpânire adecvată a
limbaje principale precum Ruby, C#, .NET, Perl, Python, Java, PHP, Windows PowerShell, și sunt
confortabil cu mediile de operare asociate Windows, Linux și Unix.
21. Cât de mult ai interacț ionat cu dezvoltarea software-ului bazat pe cloud?
Sfaturi pentru a răspunde: Împărtășește-ți cunoștințele despre utilizarea platformelor cloud, provisionarea de noi instanțe,
codarea noilor iterații de software cu API-urile sau kiturile de dezvoltare software ale furnizorului de cloud,
configurarea clusterelor pentru a scala capacitatea de calcul, gestionarea cicli de viață a sarcinilor de lucru și așa mai departe. Aceasta este
ocazie perfectă pentru a discuta despre instanțele cloud bazate pe containere ca alternativă la cele convenționale
VM-uri. Calculul în cloud bazat pe evenimente, cum ar fi AWS Lambda, oferă o altă abordare pentru software
dezvoltare, un avantaj pentru candidații DevOps experimentați. În interviul tău, menționează experiența
gestionarea datelor mari, care utilizează infrastructuri cloud foarte scalabile pentru a aborda calculul complex
sarcini.
22. Ce alte instrumente cunoș ti care te-ar putea ajuta în acest rol?
Sfaturi pentru a răspunde: DevOps este atât de divers și incluziv încât rareori se termină cu programarea, testarea și
sisteme. Un proiect DevOps ar putea depinde de platforme de baze de date precum SQL sau NoSQL, structură de date
servere precum Redis, sau sisteme de urmărire a problemelor de configurare și management precum Redmine. Web
aplicațiile sunt populare pentru întreprinderile moderne, creând un fundal cu servere Web, cum ar fi
Microsoft Internet Information Services, Apache Tomcat sau alte servere web, benefice. Asigurați-vă că
pentru a transmite că ești familiarizat cu tehnicile de gestionare a ciclului de viață al aplicațiilor Agile și
unelte.
23. Eș ti familiarizat doar cu Linux sau ai lucrat ș i în medii Windows?
Sfaturi pentru a răspunde: Demonstrează cât mai mult posibil o înțelegere clară a ambelor medii.
inclusiv instrumentele cheie.
24. Cum poț i reduce timpul de încărcare al unui site web dinamic?
Sfaturi pentru a răspunde: Vorbește despre optimizarea paginilor web, paginile web cache, calitatea găzduirii web.
fișiere text comprimate, ajustarea fină Apache.
25. Descrie experienț a ta în implementarea desfăș urării continue?
Sfaturi pentru a răspunde: Răspundeți cu o listă cuprinzătoare a tuturor instrumentelor pe care le-ați folosit. Includeți inferențe despre
provocările cu care te-ai confruntat și cum le-ai abordat.
26. Cum ai asigura trasabilitatea?
Sfaturi pentru a răspunde: Această întrebare explorează atitudinea ta față de metrici, înregistrări, parcursul tranzacțiilor și
raportare. Ar trebui să fii în măsură să identifici acea metrică, monitorizarea și înregistrarea trebuie să fie o parte esențială
a sistemului software și că fără ele, software-ul nu va fi practic capabil să
aparține întreținute și diagnosticate. Include cuvinte precum SysLog, Splunk, urmărirea erorilor, Nagios,
SCOM, Avicode
27. Care a fost cea mai mare realizare a ta într-un proiect recent?
Sfaturi pentru a răspunde: Asigură-te că demonstrezi înțelegerea ta perfectă atât a dezvoltării, cât și a ...
operațiuni. Nu lăsați răspunsul vostru să se incline spre o anumită abilități ignorând cealaltă. Chiar și dacă
ai lucrat într-un mediu în care a trebuit să lucrezi mai mult cu un set de abilități, asigură-te că
explică intervievatorului că ești agil în funcție de nevoile organizației tale.
28. Ce probleme ai întâmpinat ș i cum le-ai rezolvat într-un mod care să răspundă nevoilor echipei?
obiective?
Sfaturi pentru a răspunde: Această întrebare are scopul de a afla cât de bine poți face față stresului și neconformității.
la lucru. Vorbește despre abilitățile tale de leadership pentru a gestiona și motiva echipa să rezolve problemele
[Link] about CI, release management and other tools to keep interdisciplinary projects on
pistă.
29. Eș ti mai mult Dev sau Ops?
Sfaturi pentru a răspunde: Aceasta este probabil cea mai complicată întrebare pe care ai putea să o întâlnești în interviu.
Subliniează faptul că acest lucru depinde foarte mult de locul de muncă, de compania pentru care lucrezi și de abilitățile tale.
al oamenilor implicați. Trebuie să fii cu adevărat capabil să alternezi între ambele părți ale gardului în orice moment.
timpul dat. Vorbește despre experiența ta și demonstrează cum ești agil în ambele.
30. Ce pregătire specială sau educaț ie ț i-a fost necesară pentru a deveni inginer DevOps?
Sfaturi pentru a răspunde: DevOps este mai mult o mentalitate sau o filozofie decât un set de abilități. Tipic
abilitățile tehnice asociate cu inginerii DevOps de astăzi sunt administrarea sistemelor Linux, scriptingul,
și experiență cu unul dintre numeroasele instrumente de integrare continuă sau gestionare a configurației, cum ar fi
Jenkins și Chef. Totul se reduce la faptul că orice set de abilități pe care îl aveți, deși important, este
nu este la fel de important ca abilitatea de a învăța rapid noi abilități pentru a satisface nevoile. Totul ține de
recunoașterea modelelor și având capacitatea de a combina experiențele tale cu cerințele actuale.
Competență în administrarea sistemelor Windows și Linux, dezvoltarea scripturilor, o înțelegere a
programare structurată și design orientat pe obiect, și experiență în crearea și consumarea
API-urile RESTful te vor duce departe.
31) Explica ce este DevOps?
Este un termen nou emergent în domeniul IT, care nu este altceva decât o practică ce pune accent pe
colaborarea și comunicarea atât a dezvoltatorilor de software, cât și a altor specialiști în tehnologia informației (IT)
profesioniști. Se concentrează pe livrarea mai rapidă a produselor software și pe reducerea ratei de eșec a
lansări.
32) Menț ionaț i care sunt aspectele cheie sau principiul din spatele DevOps?
Aspectele cheie sau principiul din spatele DevOps este
Infrastructură ca program
Implementare continuă
Automatizare
• Monitorizare
• Security
33) Care sunt operaț iunile de bază ale DevOps în dezvoltarea aplicaț iilor ș i cu
infrastructură?
Operațiunile de bază ale DevOps cu
Dezvoltarea aplicațiilor
• Construirea codului
• Acoperirea codului
Testare unitară
Ambalare
• Implementare
Cu infrastructură
Provisionare
• Configurare
Orchestrare
• Implementare
34) Explicaț i cum este procesată sau executată "Infrastructura codului" în AWS?
În AWS,
Codul pentru infrastructură va fi în format JSON simplu
Codul JSON va fi organizat în fișiere numite șabloane
• Aceste șabloane pot fi implementate pe AWS și apoi gestionate ca stive.
Ulterior, serviciul CloudFormation va efectua operațiuni de creare, ștergere, actualizare etc.
stivă
35) Explicaț i care este limbajul de scripting cel mai important pentru un inginer DevOps?
O limbaj de scriptare mai simplu va fi mai bun pentru un inginer DevOps. Python pare să fie foarte popular.
36) Explicaț i cum este DevOps util pentru dezvoltatori?
DevOps poate fi de ajutor pentru dezvoltatori pentru a remedia erorile și a implementa noi funcționalități rapid. De asemenea, ajută
pentru o comunicare mai clară între membrii echipei.
37) Enumeră câteva instrumente populare pentru DevOps?
Unele dintre cele mai populare instrumente pentru DevOps sunt

• Jenkins
Nagios
• Monitor
• ELK (Elasticsearch, Logstash, Kibana)
io
Jenkins
• Docker
Ansible
• Git
Collectd/Collectl
38) Menț ionează în ce caz ai folosit SSH?
Am folosit SSH pentru a mă conecta la o mașină remote și a lucra pe linia de comandă. Pe lângă asta, am
de asemenea, l-a folosit pentru a străpunge sistemul pentru a facilita comunicații securizate criptate între
două gazde neîncrezătoare peste o rețea nesigură.
Explică cum ai gestiona controlul versiunilor.
Abordarea mea pentru a gestiona controlul versiunilor ar fi să postez codul pe SourceForge sau GitHub pentru
toată lumea poate să-l vizioneze. De asemenea, voi posta lista de verificare de la ultima revizie pentru a mă asigura că orice
problemele nerezolvate sunt rezolvate.
40) Menț ionaț i care sunt tipurile de cereri Http?
Tipurile de cereri Http sunt
• OBȚINE
• CAP
• PUNE
• POST
• PATCH
• ȘTERGE
• URMĂRIȚI
• CONECTEAZĂ
• OPȚIUNI

[Link]

Ce ai făcut în ultimii 1-2 ani?

Interviurile nu trebuie să respecte un cadru specific ș i pot fi dinamice în

natură. Pentru a obț ine o perspectivă generală asupra a ceea ce a făcut un candidat, este o idee bună să
întrebaț i un inginer despre experienț ele sale profesionale recente
activităț i.

Acest lucru te va ajuta, ca manager DevOps, să înț elegi cu ce instrumente specifice ș i

tehnologii asupra cărora inginerul a lucrat în ultimii câț iva ani (acestea pot include
Git, Puppet, Jenkins, Docker, Ansible ș i limbaje de scripting). De asemenea, va dezvălui
abilitatea candidatului de a lucra în echipă, deoarece candidatul va divulga cel mai probabil
dacă a zburat singur sau a fost parte a unei structuri mai mari. Dacă răspunsul persoanei face
dacă nu includeț i aceste informaț ii, atunci aceasta este o altă întrebare pe care trebuie să o punem.

Este esenț ial să luăm în considerare rolurile în care candidatul a activat ș i sarcinile
că candidatul a realizat, chiar dacă acestea nu sunt strict necesare în cazul tău
organizaț ie sau în rolul pentru care este intervievat. Dacă prospectul nu
menț ionează uneltele exacte pe care le foloseș ti în prezent, urmate de întrebări despre acestea
unelte ș i sarcini pentru a avea o idee bună despre capacitatea sa de a asimila cunoș tinț e de asemenea
ca dependenț ele generale de operare ale acestuia sau ale acesteia. Candidaț ii buni vor fi întotdeauna

demostra o înț elegere profundă în domeniul operaț iunilor lor în timp ce altele vor
răspunde cu răspunsuri superficiale la întrebările de urmărire detaliate.

2. Cum desfăș uraț i software-ul?

Această întrebare este critică pentru orice poziț ie DevOps. Pe măsură ce tot mai multe echipe DevOps
pe măsură ce ne îndreptăm spre automatizarea ș i adoptarea celor mai bune practici de livrare continuă, este crucial
pentru a evalua dacă candidatul se simte confortabil să discute despre desfăș urarea codului ș i
dacă el sau ea înț elege cum toate cele disponibileintegrare continuă
unelteș iInstrumente DevOpspotriviț i. Dacă aveț i o tablă de desen disponibilă, lăsaț i-l sau
îi construieș te un diagramă pentru tine.

În funcț ie de răspunsurile pe care le primeș ti, poț i dezvolta linii suplimentare de întrebare.
dinamic. De exemplu: “Ai o bază de date în stivă?” “Cum faci tu
["actualizaț i schema?","Ce teste efectuaț i ș i cum le rulaț i?","Dacă toate testele"]
treci, cum este codul implementat în producț ie?" "Cum te asiguri că faci asta?
nu pierde trafic în timpul desfăș urării?

3. Cum ai gestionat desfăș urările eș uate?

Desigur, desfăș urările eș uate sunt o ocorrenț ă prea comună atunci când desfăș urăm
inginerii DevOps trebuie să fie extrem de implicaț i - trebuie să ș tie când
ceva a mers prost ș i apoi depanarea problemei cât mai repede posibil.

O modalitate bună de a evalua adecvarea unui candidat este să-i ceri să povestească istoria
o implementare eș uată ș i modul în care a fost gestionată. Întrebările specifice de urmărire pot
Cum ș tii că a existat o eș uare a desfăș urării?
în mod automat?” ș i “Ce criterii folosiț i?”

4. Dacă ceva se strică în producț ie, cum afli despre asta?

Monitorizarea este o componentă uriaș ă a muncii DevOps (ș i acest lucru se reflectă în

o multitudine de instrumente ș i platforme de monitorizare acolo). Indiferent de instrumentele specifice
pe care îl folosiț i ș i sistemul de monitorizare pe care îl utilizaț i în compania dumneavoastră, trebuie să
ș tiu cât de bine cunoscut este candidatul în planificarea ș i executarea unui monitor
strategia.

Din nou, ai putea folosi tactica povestirii: „Spune-mi despre o criză în producț ie care
ai avut, cum ai devenit constient de el ș i cum a fost rezolvat.” O poveste bună de război este
întotdeauna iluminator – te va ajuta să evaluezi nu doar cât de pricepuț i sunt candidaț ii
sunt în monitorizare, dar ș i cum gestionează crizele (presupunând că spun adevărul, de
curs).

Întrebări suplimentare de conducere: "Cu ce instrumente de monitorizare lucrezi?" "Ai făcut tu

îi alegi? Dacă da, de ce?” ș i “Cum eș ti alertat?” Am descoperit că cel mai bun
candidatii vor avea multe de împărtăș it despre expertiza lor în monitorizare ș i în special
despre tehnici avansate de monitorizare a experienț ei utilizatorului.

5. Ce se întâmplă când tastezi "mv *" într-un director cu trei subdirectoare

a, b ș i c?

Desigur, această întrebare—ș i răspunsurile—pot varia, dar ideea este de a evalua

expertiza tehnică a inginerului într-un mediu Linux, care este un „must” în
aproape toate poziț iile DevOps.

Este o idee bună să schimbi comanda bash pe măsură ce primeș ti răspunsurile. Dacă simț i
întrebările sunt prea uș oare, încearcă să ridici ș tacheta cu întrebări bash mai avansate.
exemplu, care este diferenț a între 'cmd1 ; cmd2' ș i 'cmd1 && cmd2'?

You might want to prepare a quiz sheet with a list of five to ten commands. This way,
candidatul va găsi mai uș or să răspundă.

6. Fără a folosi Docker, poț i vedea procesele care rulează în interiorul unui container?
din afară?

Ok, am înș elat aici. Nu fiecare companie foloseș teDockersau chiar containere deloc, aș a că
aceasta întrebare este un pic specifică tehnologiei. Pe baza expertizei noastre ș i a datelor
înSondajul DevOps Pulse 2016pe care l-am lansat recent, din ce în ce mai mult
companiile se deplasează către microservicii ș i arhitecturi containerizate. Aș adar, am adăugat
această întrebare pe lista.
Desigur, această întrebare este menită să determine dacă candidatul înț elege cum
containerizarea funcț ionează. În loc să întrebăm „Cum funcț ionează containerele?” sau „Ce este un
Imagine Docker?
„înț elege” asta. Alte întrebări pot include „Cum funcț ionează legarea containerelor?” sau „Cum
ș i de ce ai optimiza un Dockerfile?

7. Descrie procesul de bootare Linux.

Aceasta este o altă întrebare menită să evalueze înț elegerea sistemului de către candidat ș i
Expertiză Linux.

Un candidat bun va putea detalia ordinea corectă ș i semnificaț ia de cel puț in

unele dintre diferitele etape (de exemplu, BIOS, MBR, bootloader, kernel, iniț ializare, ș i
nivel de funcț ionare). Pentru a aprofunda mai departe, aș recomanda o întrebare de urmărire, cum ar fi „Ce
informaț iile trebuie furnizate bootloader-ului?

8. Cum funcț ionează 'traceroute'?

Orice interviu DevOps trebuie să includă întrebări despre reț ele.

Mulț i candidaț i nu vor ș ti răspunsul la această întrebare, în timp ce alț ii vor oferi
o modalitate bună de a separa grâul de neghină în DevOps este să
verifică dacă candidatul explică doar că comanda afiș ează ruta pe care o urmează pachetele
către gazda reț elei sau dacă el sau ea se adânceș te ș i în "cum."

Chiar dacă nu primeș ti un răspuns corect ș i complet, această întrebare este una bună
punct de plecare pentru o conversaț ie mai profundă în care poț i face un brainstorming cu
candidat. În acest proces, poț i încerca să găseș ti posibilităț i valide ș i să excludi
invalide pe baza unei înț elegeri solide a rutării IP.

Un alt exemplu de întrebare bună pentru a face networking pe care o folosesc adesea: „Care este
diferenț a dintre a încerca să te conectezi la un port care nu este ascultat faț ă de
la unul care este protejat prin firewall în termenii TCP?

9. Consideri că ș apte este o medie de încărcare mare?

[Link] este unPlatformă de analiză a jurnalelor alimentată de IAcare oferă sursă deschisăELK
Stivăca un serviciu cloud, aș a că facem partea noastră sănătoasă de testare a performanț ei ș i
ajustare. Avem nevoie ca inginerii noș tri DevOps să înț eleagă fundamentele sistemului
monitorizarea performanț ei atât pentru scopuri de planificare cât ș i pentru rezolvarea problemelor în
producț ie.

Această întrebare îț i permite să afli dacă candidatul înț elege semnificaț ia

încărcarea medie în primul rând. Dacă înț eleg ș i explică că nu este utilizarea CPU,
este o deschidere grozavă pentru o discuț ie mai profundă despre soluț ionarea problemelor de performanț ă.

Urmăriri utile: „Este posibil să observi o încărcare mare cu o utilizare scăzută a CPU-ului?” „Dacă da,
{"reason":"Ce ar putea fi motivele?","check":"Cum ai verifica?"}

10. Realizează un test de codare FizzBuzz.

Ideea principală a testului FizzBuzz este de a observa cum un dezvoltator gestionează o programare uș oară
sarcină. Simulările în direct sunt o modalitate bună de a vedea cât de repede reacț ionează inginerii.
ei, cât de bine înț eleg o sarcină simplă ș i apoi o transpun în cod.

Candidatul ar trebui să:

Scrie un program sau un script care afiș ează numerele între 1 ș i

100
Pentru fiecare număr care este divizibil cu trei, se imprimă "Fizz"
Pentru fiecare număr care este divizibil cu cinci, se tipăreș te „Buzz”
Pentru fiecare număr care este divizibil atât cu trei, cât ș i cu cinci, "FizzBuzz" este
imprimat
Cei mai buni dezvoltatori ar trebui să fie capabili să scrie un astfel de program pe hârtie într-un
câteva minute. Vezi cum scriu codul, întreabă-i de ce au scris specific
părț i în anumite moduri ș i apoi verifică valabilitatea codului.

Explică ce este DevOps?

DevOps este un termen nou apărut în domeniul IT, care nu este nimic altceva decât o practică ce subliniază colaborarea ș i
comunicarea atât a dezvoltatorilor de software, cât ș i a altor profesioniș ti în tehnologia informaț iei (IT). Scopul său este
stabilirea unei culturi ș i a unui mediu în care construirea, testarea ș i lansarea de software să se poată desfăș ura rapid,
frecvent ș i mai fiabil.
DevOps se concentrează pe 4 domenii principale în IT?

1. Cultură.
2. Organizaț ie (stil inclusiv roluri).
3. Procese.
4. Unelte.

Care sunt cele nouă lucruri care constituie Dev & Ops?

- 1 pas construcț ie ș i desfăș urare

Infrastructură automatizată
- Controlul versiunii partajat
- Metrici partajaț i
- Împărț iț i codul cu steaguri
- Botii IM IRC
Atitudine sănătoasă faț ă de eș ec
- Trust and respect
Nu-i învinovăț i pe ceilalț i

1) Explicaț i ce este DevOps?

Este un termen nou emergent în domeniul IT, care nu este altceva decât o practicã care puntează
colaborarea și comunicarea atât a dezvoltatorilor de software, cât și a altor informații-
profesioniști în tehnologia informației (IT). Se concentrează pe livrarea produsului software mai repede și pe reducerea
rata de eșec a lansărilor.
2) Menț ionaț i care sunt aspectele cheie sau principiul din spatele DevOps?

Aspectele cheie sau principiul din spatele DevOps este

Infrastructure ca cod
Dezvoltare continuă
Automatizare
Monitorizare
Security
3) Care sunt operaț iunile de bază ale DevOps în dezvoltarea aplicaț iilor ș i cu
infrastructură?

Operațiile de bază ale DevOps cu

Dezvoltarea aplicaț iilor

Construirea codului
Acoperirea codului
Testarea unităț ilor
Ambalaj
 Implementare
Cu infrastructură
Furnizare
Configuraț ie
Orchestrare
Dezvoltare
4) Explicaț i cum este procesat sau executat "Infrastructure of code" în AWS?

În AWS,

Codul pentru infrastructură va fi în format JSON simplu

Acest cod JSON va fi organizat în fiș iere numite ș abloane
Aceste ș abloane pot fi implementate pe AWS ș i apoi gestionate ca stive.
Mai târziu, serviciul CloudFormation va efectua operaț iunea de creare, ș tergere, actualizare etc. în
stiva
5) Explicaț i care limbaj de scripting este cel mai important pentru un inginer DevOps?

O limbaj de scripting mai simplu va fi mai bun pentru un inginer DevOps. Python pare a fi foarte
popular

6) Explicaț i cum DevOps este util pentru dezvoltatori?

DevOps poate fi util dezvoltatorilor pentru a corecta erorile și a implementa rapid noi funcționalități.
de asemenea, ajută la o comunicare mai clară între membrii echipei.

7) Enumeraț i unele instrumente populare pentru DevOps?

Unele dintre instrumentele populare pentru DevOps sunt

Jenkins
Nagios
Monitor
ELK (Elasticsearch, Logstash, Kibana)
io
Jenkins
Docker
Ansible
Git
Collectd/Collectl
8) Menț ionează în ce situaț ie ai folosit SSH?
Am folosit SSH pentru a mă conecta la o mașină la distanță și pentru a lucra în linia de comandă. Pe lângă aceasta,
De asemenea, l-am folosit pentru a tăia tuneluri în sistem pentru a facilita criptarea sigură.
comunicările între două gazde necontriocute pe o rețea nesigură.

9) Explicaț i cum aț i gestiona controlul versiunilor.

Abordarea mea pentru a gestiona controlul versiunilor ar fi să public codul pe SourceForge sau
GitHub, astfel încât toată lumea să poată să-l vizioneze. De asemenea, voi posta lista de verificare de la ultima revizie pentru a face
asigurați-vă că orice probleme nerezolvate sunt soluționate.
10) Menț ionaț i care sunt tipurile de cereri Http?

Tipurile de cereri Http sunt

GET
CAP
PUNE
POST
PATCH
ŞTERGE
URMĂRE
CONEXIUNE
OPTIONS
11) Explicaț i ce aț i verifica dacă un server de construire Linux începe brusc să devină lent?

Dacă un server de construire Linux începe brusc să devină lent, vei verifica următoarele trei lucruri

Nivelul aplicaț iei

rezolvarea problemelor Probleme legate de RAM, probleme de citire ș i scriere Disk I/O, probleme legate de spaț iul pe disc etc.

Verificaț i fiș ierul jurnal al aplicaț iei SAU fiș ierul jurnal al serverului de aplicaț ii, probleme de performanț ă a sistemului,
Verifică jurnalele HTTP, jurnalele tomcat etc. sau verifică jurnalele jboss, weblogic pentru a vedea dacă aplicaț ia
Depanare la nivel de sistem timpul de răspuns/receptie este problema pentru încetinire, scurgerea de memorie a oricărei aplicaț ii

Dependent Services
diagnosticare a problemelor Probleme legate de antivirus, Probleme legate de firewall, Probleme de reț ea, Răspuns server SMTP

12) Cum ai ș ti dacă placa ta video poate rula Unity?

Când folosești comanda

/usr/lib/nux/unity_support_test-p

va oferi un output detaliat despre cerințele Unity și dacă acestea sunt îndeplinite, atunci videoclipul tău
cardul poate rula unity.

13) Explicaț i cum să activaț i sunetul de pornire în Ubuntu?

Pentru a activa sunetul de pornire

Faceț i clic pe echipamentul de control ș i apoi faceț i clic pe Aplicaț ii la pornire

În fereastra Preferinț e aplicaț ie Startup, faceț i clic pe Adaugă pentru a adăuga o intrare
Apoi completaț i informaț iile în caseta de comentarii, cum ar fi Nume, Comandă ș i Comentariu

/usr/bin/canberra-gtk-play—id="desktop-login"—description="redă sunet de conectare"

Deconectaț i-vă ș i apoi conectaț i-vă din nou când aț i terminat
YDe asemenea, îl poți deschide cu o tastă de comandăCtrl+Alt+T.

14) Care este modalitatea mai rapidă de a deschide un terminal Ubuntu într-un anumit director?

Pentru a deschide terminalul Ubuntu într-un director anume, poți folosi un scurtătură personalizată de taste.

Pentru a face asta, în câmpul de comandă al unei noi tastaturi personalizate, scrie genome–terminal– –
working–directory = /path/to/dir.

15) Explicaț i cum puteț i obț ine culoarea curentă a ecranului curent pe desktopul Ubuntu?

Puteți deschide imaginea de fundal în The Gimp (editor de imagini) și apoi folosi pipeta.
un instrument pentru a selecta culoarea pe un punct specific. Îți oferă valoarea RGB a culorii de la acel punct
punct.

16) Explicaț i cum creaț i lansatoare pe desktop în Ubuntu?

Pentru a crea lansatoare pe desktop în Ubuntu, poți folosi

ALT+F2 apoi scrie „gnome-desktop-item-edit–create-new~/desktop”, va lansa vechiul

Dialog GUI și creați un lansator pe desktop-ul dvs.

17) Explică ce este Memcached?

Memcached este un obiect de memorie distribuit, performant, gratuit și open source.

sistem de caching. Obiectivul principal al Memcached este de a îmbunătăți timpul de răspuns pentru
date care pot fi altfel recuperate sau construite dintr-o altă sursă sau bază de date.
este folosit pentru a evita necesitatea de a opera baza de date SQL sau altă sursă în mod repetat pentru a obține
date pentru cererea concurentă.
Memcached poate fi folosit pentru

Rețele sociale-> Caching-ul profilului

Agregarea de conținut -> HTML/ Cache de pagină
Targetare a anunțurilor -> Cookie/urmărirea profilului
Relație -> Cache de sesiune
•Comerț electronic-> Cache de sesiune și HTML
Servicii bazate pe locație -> Scalarea interogărilor bazei de date
Jocuri și divertisment-> Cache-ul sesiunii

Memcache ajută la

•Accelerează procesele de aplicare

•Determina ce să stocheze și ce să nu
•Reducerea numărului de cereri de recuperare către baza de date
Reduc accesul I/O (Intrare/Ieşire) (hard disk)
Dezavantajul Memcached este

•Nu este un magazin de date persistent

•Not a database
•Nu este specific pentru o aplicație
Nu poate salva obiecte mari în cache.

18) Menț ionaț i câteva caracteristici importante ale Memcached?

Caracteristicile importante ale Memcached includ

• Tokeni CAS:A CAS token is attached to any object retrieved from cache. You can use
acele token pentru a salva obiectul actualizat.
• Callbacks: Simplifică codul
• getDelayed: Reduce timpul de așteptare al scriptului tău, care așteaptă să vină rezultatele.
înapoi de la server
• Protocol binarPuteți utiliza protocolul binar în loc de ASCII cu clientul mai nou
• Igbinary:Anterior, clientul obișnuia să facă serializarea valorii cu date complexe.
dar cu Memcached poți folosi opțiunea igbinary.
19) Explicaț i dacă este posibil să partajaț i o singură instanț ă a unui Memcache între mai multe
proiecte?

Da, este posibil să împărtășești o singură instanță de Memcache între mai multe proiecte.
Memcache este un spațiu de stocare în memorie și poți rula memcache pe unul sau mai multe servere.
De asemenea, poți configura clientul să comunice cu un set specific de instanțe. Așa că, poți rula
două procese diferite Memcache pe aceeași gazdă și totuși sunt complet
independent. Cu excepția cazului în care ți-ai partitionat datele, atunci devine necesar să știi
from which instance to get the data from or to put into.

20) Aveț i mai multe servere Memcache, în care unul dintre serverele memcacher eș uează,
ș i are datele tale, va încerca vreodată să obț ină datele cheie de la acel server eș uat?

Datele de pe serverul eșuat nu vor fi șterse, dar există o prevedere pentru eșec automat.
pe care îl poți configura pentru mai multe noduri. Comutarea pe rezervă poate fi declanșată în timpul oricărui tip de
erori la nivelul serverului socket sau Memcached și nu în timpul erorilor normale ale clientului, cum ar fi adăugarea unui
cheie existentă, etc.

21) Explicaț i cum puteț i minimiza căderile serverului Memcached?

Când o instanță eșuează, mai multe dintre ele coboară, acest lucru va pune o sarcină mai mare pe
serverul de baze de date atunci când datele pierdute sunt reîncărcate pe măsură ce clientul face o solicitare. Pentru a evita acest lucru, dacă
codul a fost scris pentru a minimiza stampedele de cache, astfel încât să aibă un impact minim
O altă modalitate este să aduceți o instanță de Memcached pe o mașină nouă folosind pierdut
adresa IP a mașinilor
Codul este o altă opțiune pentru a minimiza timpul de nefuncționare a serverelor, deoarece îți oferă libertatea de a face modificări.

lista serverelor Memcached cu muncă minimă

•Setarea valorii timeout este o altă opțiune pe care unii clienți Memcached o implementează pentru
Memcached server outage. When your Memcached server goes down, the client will keep
încercând să trimiteți o solicitare până când se atinge limita de timeout

22) Explicaț i cum puteț i actualiza Memcached când datele se schimbă?

Când datele se modifică, poți actualiza Memcached prin

• Ș tergerea cache-ului în mod proactiv:Ștergerea cache-ului atunci când se face o inserție sau o actualizare
• Resetarea cache-ului:Este similar cu prima metodă, dar în loc să ștergeți doar cheile
și așteptând următoarea solicitare pentru date pentru a reîmprospăta memoria cache, resetați valorile după
inserați sau actualizați.
23) Explicaț i ce este efectul Dogpile? Cum puteț i preveni acest efect?
Efectul dogpile se referă la evenimentul când cache-ul expiră, iar site-urile sunt supuse unui atac de trafic.
mai multe cereri făcute de client în același timp. Acest efect poate fi prevenit prin
utilizând un blocaj semafor. În acest sistem, când valoarea expiră, primul proces obține blocajul
și începe să genereze o nouă valoare.

24) Explicaț i cum Memcached nu ar trebui folosit?

Utilizarea frecventă greșită a Memcached este să-l folosești ca un depozit de date și nu ca un cache.
•Nu folosiți niciodată Memcached ca singura sursă de informații de care aveți nevoie pentru a vă rula
aplicație. Datele ar trebui să fie întotdeauna disponibile și printr-o altă sursă.
•Memcached este doar un magazin de chei sau valori și nu poate efectua interogări asupra datelor sau itera.
pentru a extrage informații
Memcached nu oferă nicio formă de securitate, nici în criptare, nici în autentificare.

25) Când serverul se închide, datele stocate în Memcached mai sunt disponibile?
Datele stocate în Memcached nu sunt durabile, așa că, dacă serverul este oprit sau repornit, atunci toate
datele stocate în Memcached sunt șterse.

26) Menț ionează care este diferenț a dintre Memcache ș i Memcached?

• Memcache:Este un addon care îți permite să lucrezi prin intermediul unor obiecte orientate.
(OOP) și interfețe procedurale. Este conceput pentru a reduce sarcina bazei de date în web dinamic
aplicații.
• Memcached: It is an extension that uses libmemcachedbibliotecă pentru a oferi API pentru
comunicarea cu serverele Memcached. Este utilizat pentru a crește web-ul dinamic
aplicații prin diminuarea încărcării bazei de date. Este cea mai nouă API.

GIT este un instrument de control al versiunilor foarte popular în comunitatea software. Multe organizații Fortune 500
folosiți GIT. Această carte conține întrebări de interviu GIT de la nivel de bază la nivel expert pe care le pune un intervievator.
Fiecare întrebare este însoțită de un răspuns, astfel încât să te poți pregăti pentru interviul de angajare pe scurt.
timp.

Am compilat această listă de întrebări GIT după ce am participat la zeci de interviuri tehnice în top-
companii de top precum - Google, Facebook, Ebay, Amazon etc.

Unele dintre întrebările de probă sunt:

Cum putem ști dacă o ramură este deja îmbinată în master în GIT?
Care este scopul comenzii git stash drop?
Ce este HEAD în GIT?
Care este cea mai populară strategie de ramificare în GIT?
Ce este SubGit?
Care este utilizarea git instaweb?
Ce sunt hooks-urile Git?
Ce este GIT?
Ce este un depozit în GIT?
Care sunt principalele beneficii ale GIT?
Care sunt dezavantajele GIT-ului?
Care sunt principalele diferențe între GIT și SVN?
Cum vei începe GIT pentru proiectul tău?
Ce este git clone în GIT?
Cum vei crea un repository în GIT?
Care sunt diferitele modalități de a începe lucrul în GIT?
GIT este scris în ce limbaj?
Ce face comanda 'git pull' în GIT intern?
Ce face comanda 'git push' în GIT în mod intern?
Ce este git stash?
Ce înseamnă ‚stage’ în GIT?
Care este scopul comenzii git config?
Cum putem vedea setările de configurare ale instalării GIT?
Cum vei scrie un mesaj cu comanda de commit în GIT?
Ce este stocat într-un obiect de commit în GIT?
Câte ramuri poți crea într-un repository GIT?
De ce creăm ramuri în GIT?
Care sunt diferitele tipuri de ramuri care pot fi create în GIT?
Cum vei crea un nou ramificat în GIT?
Cum vei adăuga o nouă funcționalitate în ramura principală?
Ce este o cerere de extragere în GIT?

[Link]

Ce este ANT?
Ans. Forma completă a ANT este Un Alt Instrument Necesitat. Ant este un instrument de construire bazat pe Java. Un instrument de construire

îndeplineș te următoarele sarcini:

Compilarea codului java în cod byte

Plasarea acestui cod byte într-un pachet
Implementarea în sistemele de producț ie
Crearea documentelor ș i pregătirea notelor de lansare.
JMS

Întrebare 1. Câte modele de mesagerie oferă JMS ș i care sunt acestea?

[Link] oferă două modele de mesagerie, publicare ș i abonare ș i coadă punct la punct.

Întrebare 2. Ce este JMS (Java Messaging Service)?

[Link] este un acronim folosit pentru Java Messaging Service. Este răspunsul Java pentru crearea de software
utilizând mesagerie asincronică. Este una dintre specificaț iile oficiale ale tehnologiilor J2EE
ș i este o tehnologie cheie.

Întrebare 3. Cum se deosebeș te JMS de RPC?

În RPC, invocatorul metodei aș teaptă ca metoda să termine execuț ia ș i să returneze controlul

înapoi la invocator. Astfel, este complet sincron în natură. În timp ce în JMS mesajul
expeditorul trimite doar mesajul către destinaț ie ș i îș i continuă propriile procese. Expeditorul
nu aș teaptă ca recepț ionerul să răspundă. Acesta este un comportament asincron.

Întrebarea 4. Care sunt avantajele de bază ale JMS?

[Link] este de natură asincronă. Astfel, nu toate componentele trebuie să fie active tot timpul pentru ca
aplicaț ia pentru a funcț iona ca un întreg. Chiar dacă receptorul este oprit, MOM va stoca mesajele
în numele său ș i le va trimite odată ce va reveni. Astfel, cel puț in o parte a aplicaț iei poate
încă funcț ionează ca ș i cum nu ar exista blocaje.

Întrebare 5. Care sunt diferitele tipuri de mesaje disponibile în API-ul JMS?

[Link], TextMessage, BytesMessage, StreamMessage, ObjectMessage, MapMessage sunt

mesajele diferite disponibile în API-ul JMS.

Întrebarea 6. Care sunt diferitele paradigme de mesagerie pe care le suportă JMS?

Publică ș i Abonează adică pub/suc ș i Punct la Punct adică p2p.

Întrebare 7. Care este diferenț a dintre subiect ș i coadă?

Un subiect este utilizat de obicei pentru mesagerie de tip unu-la-mulț i, adică suportă modelul de publicare-abonare.
de mesagerie. În timp ce coada este folosită pentru mesagerie unul-la-unu, adică suportă Punct la Punct
Mesagerie.

Întrebarea 8. Care este utilizarea obiectului Message?

[Link] este un mesaj uș or, având doar antet ș i proprietăț i ș i fără conț inut.
Astfel, dacă receptorii trebuie să fie informaț i despre un eveniment ș i nu este necesar să se schimbe date,
atunci folosind Mesajul poate fi foarte eficient.
Întrebarea 9. Care este diferenț a de bază între modelul Publicare-Abonare ș i modelul P2P?

Modelul Publish Subscribe este utilizat de obicei într-o situaț ie de tip unu-la-mulț i. Este nesigur, dar foarte
rapid. Modelul P2P este folosit în situaț ii unu la unu. Este foarte fiabil.

Întrebarea 10. Care este utilizarea TextMessage?

[Link] contains instance of [Link] as it's payload. Thus it is very useful for
schimbul de date textuale. Poate fi folosit ș i pentru schimbul de date complexe de caractere, cum ar fi
un document XML.

Ques 12. What is JMS provider?

O implementare a interfeț ei JMS pentru un Middleware Orientat pe Mesaje (MOM).

Furnizorii sunt implementaț i fie ca o implementare Java JMS, fie ca un adaptor pentru o platformă non-Java.
MAMA.

Întrebarea 13. Ce este clientul JMS?

O aplicaț ie sau un proces care produce ș i/sau primeș te mesaje.

Întrebarea 14. Ce este un producent JMS?

Un client JMS care creează ș i trimite mesaje.

Întrebarea 15. Ce este un consumator JMS?

Un client JMS care primeș te mesaje.

Ques 16. What is JMS message?

Un obiect care conț ine datele care sunt transferate între clienț ii JMS.
Întrebarea 17. Ce este o coadă JMS?

O zona de pregătire care conț ine mesaje care au fost trimise ș i aș teaptă să fie citite.
Reț ineț i că, spre deosebire de ceea ce sugerează numele coadă, mesajele nu trebuie să fie livrate în
comanda trimisă. Dacă piscina bean-urilor conduse de mesaje conț ine mai mult de o instanț ă, atunci
mesajele pot fi procesate concurent ș i, prin urmare, este posibil ca un mesaj mai târziu să fie
prelucrat mai devreme decât unul anterior. O coadă JMS garantează doar că fiecare mesaj este
prelucrat doar o dată.

Întrebarea 18. Ce este un topic JMS?

Un mecanism de distribuț ie pentru publicarea mesajelor care sunt livrate mai multor abonaț i.
Întrebare 19. Ce este JMS?

[Link] Message Service (JMS): O interfaț ă implementată de majoritatea containerelor J2EE pentru a oferi
comportamentul de coadă punct-la-punct ș i subiect (publicare/subscriere). JMS este frecvent utilizat de EJB-uri
care trebuie să înceapă un alt proces în mod asincron.
De exemplu, în loc să trimită un email direct dintr-un Enterprise JavaBean, bean-ul poate
alege să pui mesajul pe o coadă JMS pentru a fi gestionat de un Bean condus de mesaje
(o altă formă de EJB) sau un alt sistem din întreprindere. Această tehnică permite EJB-ului să returneze
pentru a gestiona cererile imediat în loc să aș tepte un proces potenț ial lung
complet.

Întrebarea 20. Ce tip de mesagerie este oferit de JMS?

Răspuns: Atât sincron cât ș i asincron.

Întrebare 21. Câte modele de mesagerie furnizează JMS ș i care sunt acestea?

[Link] oferă două modele de mesagerie, publicare ș i abonare ș i coada punct la punct.
Întrebare 22. Care este modelul punct-la-punct în JMS?

Un model punct-la-punct se bazează pe conceptul unei cozi de mesaje: Expeditorii trimit

mesajele în coadă, iar receptorul citeș te mesajele din această coadă. În sistemul punct la punct
model, mai mulț i receptori pot exista, ataș aț i la aceeaș i coadă. Cu toate acestea, (Orientat pe Mesaje
Middleware)MOM va livra mesajul doar către unul dintre ei. La care depinde de MOM.
implementare.

Întrebare 23. Ce este modelul de publicare ș i abonare în JMS?

Un model de publicare-abonare se bazează pe conceptul de subiect al mesajului: Publicatorii trimit

mesaje într-un subiect, iar toț i abonaț ii subiectului dat primesc aceste mesaje.

Întrebare 24. Ce este un obiect administrat JMS?

Un obiect JMS preconfigurat (o fabrică de conexiuni manager de resurse sau o destinaț ie)
creat de un administrator pentru utilizarea clienț ilor JMS ș i plasat într-un spaț iu de nume JNDI.

Întrebare 25. Ce este mesageria publicare/abonare?

Răspuns. Cu transmiterea mesajelor prin publicaț ie/subscriere, aplicaț ia/clientul care trimite stabileș te un nume.
subiect în broker/server-ul JMS ș i publică mesaje în această coadă. Clienț ii care primesc
înregistrează-te (în mod specific, abonează-te) prin intermediul brokerului la mesaje pe subiect; fiecare abonat la un subiect

primeș te fiecare mesaj publicat pe acel subiect. Există o relaț ie de tip unu-la-mulț i între
clientul de publicare ș i clienț ii abonaț i.

Întrebare 26. Care sunt părț ile principale ale aplicaț iilor JMS?

Răspuns. Părț ile principale ale aplicaț iilor JMS sunt:

--Factory de Conexiune ș i Destinaț ie
--Conexiune
--Sesiune
--ProducătorMesaje
--ConsumatorMesaje
--Message
Întrebarea 27. Ce este mesageria?

Mesajele sunt o metodă de comunicare între componentele software sau aplicaț ii.
Un sistem de mesagerie este o facilitate peer-to-peer: Un client de mesagerie poate trimite mesaje către, ș i
primeș te mesaje de la orice alt client. Fiecare client se conectează la un agent de mesagerie care
oferă facilităț i pentru a crea, trimite, recepț iona ș i citi mesaje.
Mesajele permit comunicarea distribuită care este slab legată. Un component trimite un
mesaj către o destinaț ie, iar destinatarul poate recupera mesajul de la destinaț ie.
Cu toate acestea, expeditorul ș i receptorul nu trebuie să fie disponibili în acelaș i timp pentru a
comunica. De fapt, expeditorul nu trebuie să ș tie nimic despre destinatar; nici nu...
destinatarul trebuie să ș tie ceva despre expeditor. Expeditorul ș i destinatarul trebuie să
ș tiu doar ce format de mesaj ș i ce destinaț ie să folosesc. În acest sens, mesajele diferă
de la tehnologii strâns legate, cum ar fi Invocarea Metodei de la Distanț ă (RMI), care necesită un
aplicaț ie pentru a cunoaș te metodele unei aplicaț ii de la distanț ă.

Mesajele diferă de poș ta electronică (e-mail), care este o metodă de comunicare.

între oameni sau între aplicaț ii software ș i oameni. Mesajele sunt folosite pentru
comunicarea între aplicaț iile software sau componentele software.
Mesajele sunt un mecanism prin care datele pot fi transmise de la o aplicaț ie la alta
aplicaț ie.

Întrebarea 28. Care este rolul furnizorului JMS?

Ans. Furnizorul JMS se ocupă de securitatea mesajelor, conversia datelor ș i clientul

triggering. The JMS provider specifies the level of encryption and the security level of the
mesaj, cel mai bun tip de date pentru clientul non-JMS.

Întrebarea 29. Care este diferenț a dintre Java Mail ș i JMS Queue?
[Link] este platforma ideală de mesagerie de înaltă performanț ă pentru mesageria intrabusiness, cu întreaga
control programatic asupra calităț ii serviciului ș i opț iunilor de livrare.
JavaMail oferă un numitor comun, lent, dar uș or de citit pentru mesaje utilizând
infrastructura deja disponibilă pe practic fiecare platformă de calcul.

Întrebare 30. Defineste specificaț ia JMS tranzacț ii?

Specificaț ia JMS defineș te mecanisme de tranzacț ie care permit clienț ilor să trimită ș i să primească
grupuri de mesaje logic delimitate ca o unitate unică de informaț ie. O sesiune poate fi marcată
aș a cum a fost tranzacț ionat. Înseamnă că toate mesajele trimise într-o sesiune sunt considerate părț i ale unei
tranzacț ie. Un set de mesaje poate fi confirmat (metoda commit()) sau anulat (rollback())
metodă). Dacă un furnizor suportă tranzacț ii distribuite, se recomandă să folosească XAResource
API.

Întrebarea 31. Ce este mesageria sincronă?

Mesajele sincrone implică un client care aș teaptă ca serverul să răspundă la un mesaj.

Aș adar, dacă un capăt este jos, întreaga comunicare va eș ua.
Întrebare 32. Ce este mesageria asincronă?

Mesajele asincrone implică un client care nu aș teaptă un mesaj de la server.

An event is used to trigger a message from a server. So even if the client is down , the messaging
va finaliza cu succes.

Întrebare 33. Cum comunică un client tipic?

Raspuns.1. Folosiț i JNDI pentru a localiza obiecte administrative.

2. Localizaț i un singur obiect ConnectionFactory.

3. Localizaț i unul sau mai multe obiecte Destinaț ie.
4. Folosiț i ConnectionFactory pentru a crea o conexiune JMS.
5. Folosiț i Conexiunea pentru a crea una sau mai multe Sesiuni.
6. Folosiț i o sesiune ș i destinaț iile pentru a crea MessageProducers ș i MessageConsumers
nevoia.
7. Efectuează-ț i comunicarea.

Întrebare 34. Ce este o sesiune JMS?

Un context cu fir unic pentru trimiterea ș i primirea mesajelor JMS. O sesiune JMS poate fi
nefericit, tranzacț ionat local sau participând la o tranzacț ie distribuită.

Întrebare 35. Care este utilizarea JMS? În ce situaț ii folosim JMS? Putem trimite
mesaj de la un server la alt server folosind JMS?
[Link] este platforma ideală de mesagerie de înaltă performanț ă pentru mesageria intra-afaceri, cu capabilităț i complete
control programatic asupra calităț ii serviciului ș i opț iunilor de livrare.

Întrebare 36. Care este diferenț a între subscripț iile durabile ș i cele non-durabile?

Ans. Punct-la-punct (PTP). Acest model permite schimbul de mesaje prin intermediul coadrelor create pentru unele
scopuri. Un client poate trimite ș i primi mesaje dintr-o sau mai multe cozi. Modelul PTP este
mai uș or decât modelul pub/sub.
O abonare durabilă oferă unui abonat libertatea de a primi toate mesajele de la un subiect,
în timp ce o subscripț ie non-durabilă nu face nicio garanț ie cu privire la mesajele trimise de
alț ii când un client a fost deconectat de la un subiect.

Întrebare 37. Care este diferenț a între producătorul de mesaje ș i consumatorul de mesaje?

Răspuns. În modelul Publicare/Abonare:

Un sistem de mesagerie publicare/abonare (pub/sub) suportă un model bazat pe evenimente unde
consumatorii ș i producătorii de informaț ii participă la transmiterea mesajelor. Producătorii
evenimentele "publică", în timp ce consumatorii "se abonează" la evenimentele de interes ș i consumă evenimentele.
Producătorii asociază mesajele cu un anumit subiect, iar sistemul de mesagerie direcț ionează mesajele.
pentru consumatori, pe baza temelor în care consumatorii îș i exprimă interesul.

În modelul Point-To-Point:
În sistemele de mesagerie punct la punct, mesajele sunt rutate către un consumator individual care
menț ine o coadă de mesaje "în curs de sosire". Aplicaț iile de mesagerie trimit mesaje către un
coada specificată, iar clienț ii recuperează mesaje dintr-o coadă.
Întrebare 38. Ce este o aplicaț ie JMS?

Unul sau mai mulț i clienț i JMS care schimbă mesaje.

Întrebarea 39. Ce tip de mesagerie este furnizată de JMS?

Atât sincron cât ș i asincron sunt furnizate de JMS

Întrebare 40. Cum diferă JMS de RPC?

În RPC, invocatorul metodei aș teaptă ca metoda să termine execuț ia ș i să returneze controlul.

înapoi la apelant. Astfel, este complet sincronic în natură. În timp ce în JMS, mesajul
expeditorul trimite doar mesajul către destinaț ie ș i continuă să-ș i efectueze propriile procese. Expeditorul
nu aș teaptă ca receptorul să răspundă. Acesta este un comportament asincron.

Întrebare 41. Ce este API-ul JMS?

Ans. Serviciul de Mesaje Java este o API Java care permite aplicaț iilor să creeze, să trimită, să primească,
ș i citirea mesajelor. Proiectat de Sun ș i mai multe companii partenere, API-ul JMS defineș te o
set comun de interfete si semantica asociata care permit programelor scrise in Java
limbaj de programare pentru a comunica cu alte implementări de mesagerie.
API-ul JMS minimizează setul de concepte pe care un programator trebuie să le înveț e pentru a utiliza produsele de mesagerie
dar oferă suficiente caracteristici pentru a sprijini aplicaț ii de mesagerie sofisticate. De asemenea, îș i propune să
maximizarea portabilităț ii aplicaț iilor JMS între furnizorii JMS în aceeaș i mesagerie
domeniu.
API-ul JMS permite comunicarea care nu este doar slab cuplată, ci ș i
* Asynchronous. A JMS provider can deliver messages to a client as they arrive; a client does not
trebuie să solicit mesaje pentru a le primi.
* Fiabil. API-ul JMS poate asigura că un mesaj este livrat o dată ș i doar o dată. Niveluri mai joase
de fiabilitate sunt disponibile pentru aplicaț ii care îș i pot permite să piardă mesaje sau să primească
mesaje duplicate.
Specificaț ia JMS a fost publicată pentru prima dată în august 1998. Cea mai recentă versiune a JMS
Specificaț ia este Versiunea 1.1, care a fost lansată în aprilie 2002. Puteț i descărca o copie a
Specificaț ie de pe site-ul JMS, [Link]
Întrebare 42. Ce este un client JMS?

Un program în limbajul Java care trimite sau primeș te mesaje.

Întrebarea 43. Oferiț i un exemplu de utilizare a modelului punct-la-punct.

Răspuns. Modelul punct-la-punct este utilizat atunci când informaț ia este specifică unui singur client.
de exemplu, un client poate trimite un mesaj pentru o imprimare, iar serverul poate trimite informaț ii înapoi
acestui client după finalizarea lucrării de imprimare.

Ques 44. What is Producer and Consumer?

[Link] permite unui servlet să delege procesarea către un proces batch fie pe acelaș i
maș ină sau pe o maș ină separată. Servletul creează un mesaj ș i îl trimite într-o coadă.
servletul se încheie imediat ș i când procesul de batch este gata, procesează mesajul.
Mesajele sunt, prin urmare, compuse din trei componente principale:
Un Producător creează mesaje ș i le trimite într-o Coadă. Producătorul ar putea fi ceva
ca un Servlet.
O coadă stochează mesajele de la Produse ș i le oferă unui Consumator atunci când este gata.
Coada este implementată de furnizorul de mesaje.
Un Consumator procesează mesajele pe măsură ce devin disponibile în Coada. Consumatorul este
de obicei un bean care implementează interfaț a MessageListener.

Întrebare 46. Care este rolul furnizorului JMS?

Răspuns. Furnizorul JMS se ocupă de securitatea mesajelor, conversia datelor ș i clientul.

declanș are. Furnizorul JMS specifică nivelul de criptare ș i nivelul de securitate al
mesaj, cel mai bun tip de date pentru clientul non-JMS.

Întrebare 48. Care este diferenț a dintre Message Byte ș i Message Stream?

[Link] Mesajul stochează datele în octeț i. Astfel, mesajul este un flux continuu de octeț i.
În timp ce Mesajul Stream menț ine o limită între diferitele tipuri de date stocate
deoarece stochează ș i informaț iile despre tip împreună cu valoarea primitivelor stocate.
Mesajul Bytes permite citirea datelor folosind orice tip. Astfel, chiar dacă încărcătura ta conț ine un lung
valoare, poț i invoca o metodă pentru a citi un scurt ș i îț i va returna ceva. Nu va da
ai un set de date semantic corect, dar apelul va reuș i să citească primele două octeț i de date.
This is strictly prohibited in the Stream Message. It maintains the type information of the data
fiind stocată ș i impune reguli stricte de conversie asupra datelor citite.

Întrebare 49. Eș ti conș tient de vreo produs major JMS disponibil pe piaț ă?
Seria MQ a IBM este unul dintre cele mai populare produse utilizate ca Middleware orientat pe mesaje.
Unele dintre celelalte produse sunt SonicMQ, iBus etc. Serverul de aplicaț ii Weblogic vine de asemenea cu
suport încorporat pentru mesageria JMS.

Întrebare 50. Care sunt diferitele tipuri de mesaje disponibile în API-ul JMS?

[Link], MesajText, MesajBytes, MesajFlux, MesajObiect, MesajHartă sunt

mesajele diferite disponibile în API-ul JMS.

Întrebare 51. Cum lucrează API-ul JMS cu platforma J2EE?

Ans.Când API-ul JMS a fost introdus în 1998, cel mai important scop al său a fost să permită Java
aplicaț ii pentru a accesa sistemele existente de middleware orientat pe mesaje (MOM), cum ar fi
MQSeries de la IBM. De atunci, mulț i furnizori au adoptat ș i implementat JMS
API, astfel încât un produs JMS să poată oferi acum o capacitate completă de mesagerie pentru o întreprindere.
De la versiunea 1.3 a platformei J2EE ("platforma J2EE 1.3"), API-ul JMS a fost un
parte integrantă a platformei, iar dezvoltatorii de aplicaț ii pot folosi mesagerie cu componente
folosind API-urile J2EE ("componente J2EE").
API-ul JMS în platforma J2EE are următoarele caracteristici.
* Clienț ii aplicaț iei, componentele Enterprise JavaBeans (EJB) ș i componentele web pot trimite
sau să primească sincronic un mesaj JMS. Clienț ii aplicaț iei pot, de asemenea, să primească JMS
mesaje asincron. (Applet-urile, totuș i, nu sunt obligate să suporte API-ul JMS.)
Boabele orientate pe mesaje, care sunt un tip de boabe de întreprindere, permit comunicarea asincronă
consumul de mesaje. Un furnizor JMS poate implementa opț ional procesarea concurentă a
mesaje de către boabe conduse de mesaje.
* Mesajele trimise ș i primite pot participa la tranzacț ii distribuite.

API-ul JMS îmbunătăț eș te platforma J2EE prin simplificarea dezvoltării de întreprindere, permiț ând dezvoltarea laxă
interacț iuni cuplată, fiabile, asincrone între componente J2EE ș i sisteme legate
capabil să trimită mesaje. Un dezvoltator poate adăuga cu uș urinț ă un nou comportament unei aplicaț ii J2EE cu
evenimente de afaceri existente prin adăugarea unei noi boabe bazate pe mesaje pentru a opera pe probleme specifice de afaceri
evenimente. Arhitectura containerului EJB a platformei J2EE, în plus, îmbunătăț eș te API-ul JMS prin
oferind suport pentru tranzacț ii distribuite ș i permiț ând consumul concurent de
mesaje.
O altă tehnologie a platformei J2EE, Arhitectura Connector J2EE, oferă o integrare strânsă
între aplicaț iile J2EE ș i sistemele existente de Informaț ii Empresariales (EIS). API-ul JMS, pe
pe de altă parte, permite o interacț iune foarte slab legată între aplicaț iile J2EE ș i cele existente
Sisteme EIS.
La versiunea 1.4 a platformei J2EE, furnizorul JMS poate fi integrat cu aplicaț ia
server folosind Arhitectura de Conector J2EE. Accesaț i furnizorul JMS printr-o resursă
adapter. Pentru mai multe informaț ii, consultaț i Specificaț ia Enterprise JavaBeans, v2.1, ș i J2EE
Specificaț ia arhitecturii conectorului, v1.5.

Întrebarea 52. Care este rolul JMS în dezvoltarea soluț iilor de afaceri?

[Link] este utilizat de obicei în următoarele scenarii

1. Integrarea aplicaț iilor de afaceri: - Unde o aplicaț ie moș tenită este integrată cu o nouă
aplicaț ie prin mesagerie.
2. B2B sau Business to Business: - Afacerile pot interacț iona între ele prin mesagerie deoarece
JMS permite organizaț iilor să colaboreze fără a-ș i lega strâns sistemele de afaceri.
3. Unităț i disperse geografic: - JMS poate asigura schimbul sigur de date între
unităț i dispersate geografic ale unei organizaț ii.
4. Aplicaț ii de tipul unul la multe: - Aplicaț iile care trebuie să transmită date în pachete sunt enorme
numărul de clienț i într-o relaț ie de tip unul-la-mulț i sunt candidaț i buni pentru utilizarea JMS. Tipic astfel de
aplicaț iile sunt site-uri de licitaț ie, servicii de cotaț ii bursiere etc.

Întrebare 56. De ce [Link] ș i [Link]

apelurile generează JMSException cu mesajul "ORA - 4020 - blocaj detectat în timp ce încercaț i să
obiect de blocare

[Link] ș i apelurile de dezabonare necesită acces exclusiv la Topicuri. Dacă

există operaț iuni JMS pendente (trimitere/publicare/receptie) pe aceeaș i Temă înaintea acestor apeluri
sunt emise, excepț ia ORA - 4020 este ridicată.
Există două soluț ii la problemă:
1. Încercaț i să izolaț i apelurile pentru createDurableSubscriber ș i unsubscribe în timpul configurării sau curăț ării
faza în care nu există alte operaț iuni JMS care au loc pe subiect. Asta va asigura că
resursele necesare nu sunt deț inute de alte apeluri operaț ionale JMS. Prin urmare, eroarea ORA - 4020
nu va fi majorat.
2. Emiteț i un apel [Link] înainte de a apela createDurableSubscriber ș i apelul unsubscribe.

Întrebare 57. De ce nu funcț ionează întotdeauna AQ_ADMINISTRATOR_ROLE sau AQ_USER_ROLE pentru AQ

aplicaț ii care folosesc API-ul Java/JMS?

În plus faț ă de acordarea rolurilor, ar trebui să acordaț i ș i permisiunea de execuț ie utilizatorului.

următoarele pachete:
* acordaț i execuț ia pe sys.dbms_aqin la <userid>
* acordaț i executarea pe sys.dbms_aqjms către <userid>
Întrebare 59. Care sunt cele trei componente ale unui mesaj?

Un mesaj JMS constă în trei părț i:

Antetul mesajului - Pentru identificarea mesajului. De exemplu, antetul este utilizat pentru a determina dacă un
mesajul dat este potrivit pentru un "abonat"
Proprietăț i - Pentru câmpuri de antet specifice aplicaț iei, specifice furnizorului ș i opț ionale
Corpul - Deț ine conț inutul mesajului. Sunt acceptate mai multe formate, inclusiv TextMessage,
care învăluie un String simplu, care învăluie obiecte Java arbitrare (care trebuie să fie serializabile). Altceva
formatele sunt, de asemenea, acceptate.

Întrebare 60. Care sunt tipurile de mesagerie?

Există două tipuri de mesagerie. Mesageria sincronă implică un client care aș teaptă pentru
serverul să răspundă la un mesaj. Mesajele asincrone implică un client care nu
aș teptaț i un mesaj de la server. Un eveniment este folosit pentru a declanș a un mesaj de la un server.

Întrebare 61. Care este diferenț a între Point to Point ș i Publish/Subscribe?

Punct-la-punct (P2P)
În sistemul punct-la-punct, mesajele sunt trimise prin intermediul coș urilor. Mesajele sunt plasate pe coș uri de către
producătorii de mesaje (clienț ii). Consumatorul de mesaje este responsabil pentru preluarea mesajului
din coadă. Comunicaț ia punct-la-punct este de obicei folosită atunci când un mesaj dat trebuie procesat
(receput) doar o dată de un anumit consumator. În acest fel, există un singur consumator al datului dat
mesaj.
Publicare ș i abonare (pub/sub)
În modelul de publicare ș i abonare, mesajele sunt trimise prin subiecte. Mesajele sunt publicate pe subiecte de către
producătorii de mesaje. Mesajele pot fi primite de orice consumatori care se abonează la
În acest fel, un mesaj poate fi primit sau procesat de mai mulț i consumatori.

Întrebare 62. De ce API-ul JMS nu oferă livrarea de mesaje sincronă de la început până la sfârș it ș i
notificare de livrare?

Răspuns. Unele sisteme de mesagerie oferă livrare sincronă către destinaț ii ca mecanism pentru
implementarea aplicaț iilor fiabile. Unele sisteme oferă clienț ilor diverse forme de livrare
notificare astfel încât clienț ii să poată detecta mesajele pierdute sau ignorate. Acesta nu este modelul
definit de API JMS. Mesageria API JMS oferă livrare garantată prin intermediul metodei o dată ș i ...
semantica livrării o singură dată a mesajelor PERSISTENTE. În plus, consumatorii de mesaje pot
asigurarea procesării fiabile a mesajelor utilizând fie modul CLIENT_ACKNOWLEDGE, fie
sesiuni tranzacț ionate. Acest lucru realizează o livrare fiabilă cu o sincronizare minimă ș i este
modelul de mesagerie pentru întreprinderi pe care majoritatea furnizorilor ș i dezvoltatorilor îl preferă. API-ul JMS nu defineș te un

schema mesajelor de sistem (cum ar fi notificările de livrare). Dacă o aplicaț ie necesită

recunoaș terea primirii mesajului, poate defini o recunoaș tere la nivel de aplicaț ie
mesaj.

Întrebare 63. Care sunt obiectele de bază legate de JMS necesare pentru fiecare aplicaț ie activată JMS

aplicaț ie?
Răsp. Fiecare client activat JMS trebuie să stabilească următoarele:
* Un obiect de conexiune furnizat de serverul JMS (brokerul de mesaje)
* În cadrul unei conexiuni, una sau mai multe sesiuni, care oferă un context pentru trimiterea mesajelor ș i
primire
* În cadrul unei sesiuni, fie un obiect de tip coadă, fie un obiect de tip subiect care reprezintă destinaț ia (mesajul
zonă de pregătire) în cadrul brokerului de mesaje
În cadrul unei sesiuni, obiectul corespunzător de expeditor sau publisher sau receptor sau abonat
(în funcț ie de dacă clientul este un producător de mesaje sau un consumator ș i foloseș te un sistem de tip point-to-point)

sau strategia publicare/abonare, respectiv). În cadrul unei sesiuni, un obiect mesaj (de trimis sau de
primi

Întrebare 64. Cum gestionează serverul de aplicaț ii conexiunea JMS?

Răsp.1. Serverul de aplicaț ii creează sesiunea serverului ș i le stochează într-un pool.
2. Consumatorul de conexiune foloseș te sesiunea serverului pentru a plasa mesaje în sesiunea JMS.
3. Sesiunea serverului este cea care generează sesiunea JMS.
4. Aplicaț iile scrise de programatorii de aplicaț ii creează listener-ul de mesaje.

Întrebarea 1. Ce este Log4j?

Ans.Log4j (Log pentru Java) este un cadru de jurnalizare furnizat de fundaț ia Apache pentru aplicaț iile bazate pe Java.
aplicaț ii.
În aplicaț ii, dacă doriț i să înregistraț i anumite informaț ii, cum ar fi orice eveniment declanș at sau orice
Actualizarea bazei de date a avut loc, avem nevoie să înregistrăm informaț iile sau erorile specifice pentru
utilitatea aplicaț iei.
Pentru a depana problemele din aplicaț ii, trebuie să înregistrăm erorile/excepț iile în jurnale. Pentru aceasta avem nevoie de
va folosi mecanismul log4j.
Log4j înregistrează informaț iile ș i afiș ează aceste informaț ii în diferite destinaț ii. Destinaț iile diferite sunt
numite appendere (consolă, fiș ier etc.).
Întrebare 2. Cum defineș ti înregistrarea pentru aplicaț ia ta?

Pentru a defini jurnalizarea pentru aplicaț ia dvs., trebuie să descărcaț i cadrul log4j.
([Link]) de pe site-ul apache.
Odată ce jar-urile log4j sunt descărcate, asiguraț i-vă că aceste jar-uri sunt în calea de clasă a aplicaț iei dumneavoastră.
să spunem că ai o aplicaț ie web care trebuie să adauge log4j. În acest caz, jarele log4j sunt copiate în
folderul WEB-INFO/lib al aplicaț iei tale web
creaț i un fiș ier nou, fie [Link], fie [Link], care va fi copiat în WEB-INF/classes
folder
[Link]/[Link] conț ine toată configuraț ia legată de mecanismul de logare
ș i nivelul logger-ului ș i pachetul pe care doriț i să-l definiț i nivelul logger-ului.

Example:

[Link]:

[Link]=INFO

[Link]=CONSOLE,FILE,RejRec
[Link]=[Link]

[Link]=WARN

[Link]=RejRec

[Link]=append,autoFlush,enabled,suffix,fileName

[Link]=true

[Link]=true

[Link]=true

[Link]=.yyyy-MM-dd

[Link]=E\:\\Docs\\WithoutBook\\DID\\jboss-eap-
6.2\standalone\log\[Link]

[Link]:

<log4j:configuration>

<appender name="ASYNC" class="[Link]">

<appender-ref ref="LOG"/>

</appender>

<appender name="MEETING-APP-LOG" class="[Link]">

<param name="File"
value="E:/Softwares/glassfish_dump/glassfish/domains/domain1/logs/meeting_app.log" />
<param name="Append" value="true"/> <param name="DatePattern" value="'.'yyyy-MM-dd-
a"/> <layout class="[Link]"> <param name="ConversionPattern"
value="%d{yyyy-MM-dd} %d{HH:mm:ss,SSS} %-5p [%t] %c - %m%n" /> </layout> </appender>

<logger name="[Link]" additivity="false">

<level value="warn"/>

<appender-ref ref="MEETING-APP-LOG"/>

</logger>
 <root>

<priority value="debug"/>

<appender-ref ref="ASYNC"/>

<appender-ref ref="ERROR-LOG"/>

</root>

</log4j:configuration>

Întrebarea 3. Care sunt diferitele niveluri de jurnalizare?

Există mai multe niveluri de logare pe care le poț i configura în aplicaț ia ta.
Acestea sunt FATAL, ERROR, WARN, TRACE, DEBUG, INFO SAU ALL în jurnalizarea apache. Jurnalizare implicită
nivelul este INFO.

Întrebare 4. Care sunt diferitele tipuri de jurnale?

În general, în orice aplicaț ie există două tipuri de jurnale

1. Jurnalele serverului de aplicaț ii :- Acestea sunt jurnalizările configurate la nivelul serverului de aplicaț ii.
example in tomcat,
avem fiș iere de log numite [Link], [Link], [Link], [Link], [Link]. toate aceste loguri
arată cu setările implicite definite în [Link] situat în tomcat-ul tău
folder de instalare/folder conf.
dacă doriț i setări personalizate, trebuie să schimbăm diferitele parametri din [Link] în
folderul conf al directorului tomcat.

[Link] logs:-We can define logging at each applicaiton level, For this we have to create
[Link] sau [Link] în folderul WEB-INF/classes.

Întrebare 5. Care sunt diferitele appendere care pot fi configurate în log4j?

Răspuns. Există diferite appendere pe care le putem configura în log4j: CONSOLE, FILES,
Bază de date, JMS, Înregistrarea evenimentelor

Appenderi utilizaț i în principal:

CONSOLE în log4j:-Dacă folosim acest lucru ca appender în aplicaț ia ta, log4j înregistrează informaț iile în
fereastra de consolă sau promptul de comandă care este pornit cu scriptul de pornire.
Fiș iere în log4j:-Appenderul de fiș iere este folosit pentru a înregistra informaț iile în fiș ierele noastre cu nume personalizate. când noi

când configurăm acest apendix, putem specifica numele fiș ierului.

Întrebarea 6. Care este importanț a înregistrării aplicaț iilor?

Jurnalizarea ajută ș i la depanare. Deș i sunt disponibile depanatoare, dar, sincer, durează
timpul de a depana o aplicaț ie folosind un depanator. O aplicaț ie poate fi depanaț i mai uș or
cu câteva mesaje de logare bine plasate. Aș adar, putem spune cu siguranț ă că logarea este foarte bună
instrument de depanare. Dacă jurnalizarea este făcută cu sens ș i înț elept, poate oferi un context detaliat pentru
defecț iuni ale aplicaț iilor.

În aplicaț iile distribuite (de exemplu, aplicaț ii web/la distanț ă), jurnalizarea este foarte importantă.
administratorul poate citi jurnalele pentru a afla despre problemele care au avut loc într-un anumit interval.

API-urile încorporate ale Java oferă opț iuni de înregistrare, dar acestea nu sunt atât de flexibile. O altă opț iune este să foloseș ti
Cadru de journaling open source al Apache numit log4j.

Dezavantajele aplicaț iilor de logging:

Există câteva dezavantaje ale utilizării jurnalizării în aplicaț ia dvs. De exemplu: jurnalizarea va
poluaț i codul
- creș te dimensiunea codului
- reduce viteza

Acestea sunt puncte importante deoarece, în cele din urmă, ne dorim aplicaț ii eficiente. Log4J are
soluț ia pentru asta. Puteț i activa sau dezactiva înregistrarea la timpul de execuț ie prin modificarea configuraț iei
fiș ier. Asta înseamnă că nu există modificări în codul sursă Java (binare).

Pentru a reduce codul acum în Spring Framework, poț i folosi AOP unde poț i configura logul.
mecanisme uș or.

Întrebare 7. Descrie despre nivelurile de logger în log4j.

Înainte de a utiliza cadrul log4j, cineva ar trebui să fie conș tient de diferitele categorii de mesaje de logare.
Următoarele sunt 5 categorii:

DEBBUG
Nivelul DEBUG este utilizat pentru a indica evenimente care sunt utile pentru depanarea unei aplicaț ii. Gestionarea
metoda pentru nivelul DEBUG este: debug().

INFORMAȚII
Nivelul INFO este folosit pentru a evidenț ia progresul aplicaț iei. Metoda de gestionare pentru nivelul INFO este:
info().

AVERTIZARE
Nivelul WARN este folosit pentru a indica situaț ii potenț ial periculoase. Metoda de gestionare pentru WARN
nivelul este: warn().

EROARE
Nivelul de EROARE arată mesaje de eroare care ar putea să nu fie suficient de grave ș i permit
aplicaț ie pentru a continua. Metoda de gestionare pentru nivelul ERROR este: error().

FATAL
Nivelul Fatal este folosit pentru a indica evenimente severe care pot cauza abortarea aplicaț iei.
Metoda de gestionare pentru nivelul FATAL este: fatal().
Dacă declari nivelul de jurnalizare ca debug în fiș ierul de configurare, atunci toate celelalte mesaje de jurnalizare vor
de asemenea, să fie înregistrat.

Dacă declari nivelul de logare ca fiind informaț ie în fiș ierul de configurare, atunci informaț iile, avertizările, erorile ș i logurile fatale

mesajele vor fi înregistrate.

Dacă declarati nivelul de log ca fiind avertizare în fiș ierul de configurare, atunci mesajele de log de tip avertizare, eroare ș i fatală

va fi înregistrat.
Dacă declaraț i nivelul de jurnalizare ca fiind eroare în fiș ierul de configurare, atunci mesajele de jurnalizare de eroare ș i fatale vor fi

înregistrat.
Dacă declaraț i nivelul de jurnalizare ca fiind fatal în fiș ierul de configurare, atunci doar mesajele de jurnalizare fatale vor fi

înregistrat.

Întrebare 8. Care sunt cele trei componente principale în log4j?

Există 3 componente principale care sunt folosite pentru a înregistra mesaje pe baza tipului ș i nivelului.
Aceste componente controlează, de asemenea, formatarea ș i plasarea raportului în timpul execuț iei. Aceste componente

sunt:

jurnale
- apărători
- layout-uri

Întrebarea 2. Câte tipuri diferite de drivere JDBC sunt prezente? Discutaț i-le.

Există patru tipuri de drivere JDBC.

Tip 1: Pod JDBC-ODBC plus Driver ODBC:
Primul tip de driver JDBC este JDBC-ODBC Bridge. Este un driver care oferă acces JDBC la
baze de date prin intermediul driverelor ODBC. Driverul ODBC trebuie configurat pe client pentru
podul pentru lucru. Acest tip de driver este utilizat frecvent pentru prototipare sau când nu există un driver JDBC
disponibil pentru un anumit DBMS.
Tip 2: Driver Native-API parț ial-Java:
Driverul nativ pentru API converteș te comenzile JDBC în apeluri native specifice DBMS. Asta este foarte asemănător cu
restricț ia ș oferilor de Tip 1. Clientul trebuie să aibă un anumit cod binar încărcat pe maș ina sa.
Aceș ti drivere au un avantaj faț ă de driverele de tip 1 deoarece interacț ionează direct cu
bază de date.
Tip 3: Conducător JDBC-Net Pure Java:
Conducătorii JDBC-Net sunt o soluț ie în trei straturi. Acest tip de conductor traduce apelurile JDBC în
protocol de reț ea independent de bază de date care este trimis la un server middleware. Acest server apoi
transformă acest protocol independent de DBMS într-un protocol specific DBMS, care este trimis
către o bază de date specifică. Rezultatele sunt apoi direcț ionate înapoi prin serverul middleware ș i
trimis înapoi clientului. Acest tip de soluț ie face posibilă implementarea unui client Java pur. Acesta
de asemenea, face posibilă schimbarea bazelor de date fără a afecta clientul.
Tip 4: Driver Java pur cu protocol nativ
Acestea sunt drivere Java pure care comunică direct cu baza de date a furnizorului. Ele fac acest lucru
prin conversia comenzilor JDBC direct în protocolul nativ al motorului de baze de date. Acest driver
nu are nicio traducere suplimentară sau strat de intermediere, ceea ce îmbunătăț eș te considerabil performanț a.
Ce înseamnă cuvântul cheie "static" în faț a unei variabile? A unei metode? A unei clase? Paranteze acolade
{}?
variabilă statică
- înseamnă o variabilă la nivel de clasă
metodă statică:
-nu are "acesta". Nu este permis să accesaț i membrii nestructuraț i ai clasei.
poate fi invocat chiar înainte de a fi creată o singură instanț ă a unei clase.
eg: main
clasă statică:
nu există aș a ceva.
bloc liber flotant static
este executat în momentul în care clasa este încărcată. Pot exista mai multe astfel de blocuri. Acest lucru poate fi util
pentru a încărca biblioteci native atunci când se folosesc metode native.

ex:
nativ void faAcest lucru() {
static{
[Link]("[Link]");
}

Întrebare 1. Ce este necesar pentru a configura un cluster cu JBoss?

Răspuns. Practic, pornirea JBoss cu configuraț ia 'all' conț ine tot ce este necesar pentru
clustering:
Are toate bibliotecile pentru grupare:

[Link], [Link]

Boabe grupate ([Link])

HA-JNDI

Replicările sesiunii HTTP ([Link])

Agricultură

HA-JMS

Întrebare 2. Ce componentă se ocupă de comunicarea în cluster în JBoss?

Răspuns. Framework-ul JGroups oferă servicii pentru a permite comunicaț iile peer-to-peer între
noduri într-un cluster. Este construit pe un set de protocoale de comunicaț ie de reț ea care oferă
transport, descoperire, fiabilitate ș i detectarea erorilor, ș i gestionarea apartenenț ei la cluster
servicii.
Întrebare 3. Este posibil să pui o instanț ă de server JBoss în mai multe clustere în acelaș i timp?

Răspuns. Este tehnic posibil să pui o instanț ă de server JBoss în multiple clustere simultan,
această practică nu este în general recomandată, deoarece creș te complexitatea managementului.

Întrebarea 4. Ce este JBoss cache pe scurt?

JBossCache permite distribuirea uș oară a seturilor de date în mediile tale de calcul. Este
pe baza JGroups ș i permite clusterizarea ș i disponibilitatea ridicată a acelor date. Poț i alege să
distribuiț i datele cu JBoss Messaging pentru a le muta acolo unde este necesar pentru calcul sau eveniment-
programare bazată pe

Întrebarea 5. Ce este Seam?

Răspuns. Bazat pe standardele JavaServer Faces ș i EJB 3.0, JBoss Seam unifică componenta ș i
modele de programare ș i oferă un cadru consistent ș i puternic pentru crearea rapidă de
aplicaț ii web cu Java EE 5.0. Seam simplifică dezvoltarea aplicaț iilor web ș i permite
funcț ionalitate nouă care era dificil de implementat manual înainte, cum ar fi conversaț iile cu stare,
operare multi-fereastră ș i gestionarea cererilor AJAX fine-grained concurente. Seam de asemenea unifică
ș i integrează tehnologii open source populare precum Facelets, Hibernate, iText ș i Lucene.
Întrebarea 6. Funcț ionează Seam pe alte servere de aplicaț ii în afară de JBoss?

[Link] funcț ionează perfect pe alte servere de aplicaț ii - la fel ca tot ce face Hibernate
echipa face, aceasta nu este o chestiune doar JBoss.

Întrebarea 7. Ce este JBoss JBPM?

JBoss JBPM este o platformă pentru limbile de proces. La bază există o bibliotecă Java pentru a defini
ș i execută grafice. Procesul actual construieș te, de exemplu, trimiterea de e-mailuri, sarcina utilizatorului ș i actualizarea
baze de date sunt definite pe baza acestora. Fiecare limbaj de proces este format dintr-un set de astfel de procese
construcț ii. Ș i aceasta este ceea ce este pluggable în această bibliotecă de bază. Pe deasupra bibliotecii de bază JBoss jBPM

bibliotecă, acolo sunt implementate mai multe limbaje de proces ca un set de construcț ii de proces: jPDL,
BPEL ș i fluxul de pagină SEAM:

jPDL este un limbaj de proces cu o interfaț ă clară pentru Java ș i sarcini foarte sofisticate
capabilităț i de management. Nu există un standard pentru limbajele de proces Java, aș a că este proprietar.

BPEL este un limbaj de orchestrare a serviciilor. Aș a cum s-a spus anterior, în BPEL, poț i scrie servicii noi ca un
funcț ia altor servicii. Aceasta este de obicei un component al unui Autobuz de Servicii Enterprise (ESB).

Fluxul de pagini SEAM este un limbaj care permite definirea grafică a navigaț iei între
pagini într-o aplicaț ie web SEAM.

Întrebarea 9. Ce este JBoss?

JBoss este un server de aplicaț ii open source popular bazat pe tehnologia Java EE.
Bazat pe Java EE, JBoss suportă aplicaț ii java cross-platform. A fost încorporat cu
Server web Apache Tomcat. Rulează pe orice JVM de versiuni 1.3 sau mai recente. JBoss suportă JNDI.
Servlet/JSP (Tomcat sau Jetty), EJB, JTS/JTA, JCA, JMS, Clusterizare (JavaGroups), Servicii Web
(Axis), ș i integrarea IIOP (JacORB).
Întrebare 10. Ce versiune de JBoss AS am nevoie pentru a rula Seam?

Răspuns. Pentru Seam 1.3: Seam a fost dezvoltat împotriva JBoss 4.2. Seam poate fi în continuare rulat împotriva JBoss

4.0. Documentaț ia pentru seam conț ine instrucț iuni pentru configurarea JBoss 4.0.

Pentru Seam 1.2: Deoarece Seam necesită cea mai recentă ediț ie a EJB3, trebuie să instalaț i JBoss AS din
cel mai recent installer JEMS. Asiguraț i-vă că selectaț i profilul „ejb3” sau „ejb3+clustering” pentru a include
Suport EJB3. De asemenea, fiș ierul de bibliotecă [Link] din distribuț ia Seam trebuie inclus în
fiecare aplicaț ie Seam pe care o desfăș uraț i. Consultaț i exemplele din distribuț ia Seam (în interiorul exemplarilor
directory) pentru a vedea cum să construieș ti ș i să ambalezi aplicaț ii Seam.

Întrebare 11. Pot rula Seam în afara JBoss AS?

Da, poț i rula aplicaț ii Seam în Tomcat 5.5+ obiș nuit sau în aplicaț ia Sun GlassFish.
server. Pentru a rula aplicaț ia Seam în Tomcat, ai nevoie de o serie de fiș iere bibliotecă suplimentare ș i o
câteva fiș iere de configurare pentru a iniț ia JBoss EJB3 în interiorul Tomcat. Vă rugăm să consultaț i
ț intă de construire ANT [Link] pentru exemplul de rezervare Seam (în examples/booking)
directorul distribuț iei Seam) pentru mai multe informaț ii despre cum să construieș ti un WAR Tomcat pentru Seam
aplicaț ii. Consultaț i acest articol pe blog despre cum să rulaț i Seam în serverul de aplicaț ii Glassfish al Sun.

Întrebare 12. Pot rula Seam într-un mediu J2EE?

Răspuns: Da, începând cu Seam 1.1, poț i folosi Seam în orice server de aplicaț ii J2EE, cu o singură menț iune: trebuie să
nu veț i putea folosi modulele EJB 3.0. Cu toate acestea, puteț i folosi fie Hibernate, fie JPA pentru
persistenț ă, ș i poț i folosi componentele Seam JavaBean în loc de beans de sesiune.

Întrebarea 13. Pot rula Seam cu JDK 1.4 ș i versiuni anterioare?

Nu, Seam funcț ionează doar pe JDK 5.0 ș i versiuni ulterioare. Foloseș te anotări ș i alte caracteristici ale JDK 5.0.

Întrebare 14. Cum să construieș ti clustere în JBoss?

Ans. aici este un rezumat pe scurt din exemplul dat în .org quick start:

din directorul bin al jboss-ului tău:

$ ./[Link] -c all -g DocsPartition -u [Link] -b [Link] -
[Link]=1

./[Link] = the executable

-c all = use server in jboss_home/server/all directory
-g DocsPartition = acesta este numele partiț iei, foloseș te orice, dar ar trebui să fie acelaș i pe toate nodurile
-u [Link] = aceasta este adresa multicast, de obicei alegi orice în intervalul 239.255.x.y
interval ș i ar trebui să fii bine
-b [Link] = aceasta este adresa IP a maș inii pe care se află nodul
-[Link]=1 = acesta este peerid-ul, trebuie să fie unic pentru fiecare nod.

aș a că scriptul de pornire pe care l-ai rula pe a doua ta maș ină pentru al doilea nod ar arăta
ca:
$ ./[Link] -c all-node2 -g DocsPartition -u [Link] -b [Link] -
[Link]=2
poț i folosi de asemenea nohup pentru a trimite procesul în fundal...

acum că ambele noduri ar trebui să fie funcț ionale, trebuie să activaț i ș i să configuraț i sesiunile sticky pe
serverul web ș i fiecare server.

Întrebare 2. Care sunt componentele structurii logice a bazei de date Oracle?

Există spaț ii de tabele ș i obiecte de schemă ale bazei de date.

Întrebare 3. Ce este un tabel spaț iu?

Un bază de date este împărț ită în unităț i logice de stocare numite tablespace-uri. Un tablespace este utilizat pentru
structuri logice înrudite grupate împreună.

Întrebare 4. Ce este tablespace-ul SYSTEM ș i când este creat?

Fiecare bază de date Oracle conț ine un tablespace numit SYSTEM, care este creat automat.
creată atunci când baza de date este creată. Spaț iul de tabele SYSTEM conț ine întotdeauna datele
tabelele de dicț ionar pentru întreaga bază de date.

Întrebarea 6. Ce este un schema?

O schemă este o colecț ie de obiecte de bază de date ale unui utilizator.

Întrebarea 7. Ce sunt obiectele schemă?

[Link] objects are the logical structures that directly refer to the database's data.
Obiectele schemei includ tabele, vizualizări, secvenț e, sinonime, indecș i, clustere, baze de date
declanș atoare, proceduri, funcț ii, pachete ș i linkuri de bază de date.

Întrebarea 10. Ce este o tabelă Oracle?

Un tabel este unitatea de bază a stocării datelor într-o bază de date Oracle. Tabelele unei baze de date
ț ine toate datele accesibile utilizatorului. Datele din tabel sunt stocate în rânduri ș i coloane.

Întrebarea 11. Ce este o vizualizare Oracle?

Un view este o tabelă virtuală. Fiecare view are o interogare ataș ată. (Interogarea este un SELECT
declaraț ie care identifică coloanele ș i rândurile tabelului(tabelelor) pe care le foloseș te vizualizarea.

Întrebare 21. Care sunt tipurile de sinonime?

Răspuns. Există două tipuri de sinonime: private ș i publice.

Întrebare 25. Ce sunt Clustere?

Ans. Grupurile sunt grupuri de una sau mai multe tabele stocate fizic împreună pentru a împărtăș i comun
coloane ș i sunt adesea folosite împreună.
Întrebare 26. Ce este un constrângere de integritate?

O restricț ie de integritate este o modalitate declarativă de a defini o regulă de afaceri pentru o coloană a unui tabel.

Întrebare 27. Ce este un Indice?

Un index este o structură opț ională asociată cu un tabel pentru a avea acces direct la rânduri.
care poate fi creat pentru a creș te performanț a recuperării datelor. Indexul poate fi creat pe
una sau mai multe coloane ale unei tabele.

Întrebare 2. De ce este important ciclul de viaț ă al dezvoltării software-ului?

[Link] serveș te ca un ghid pentru proiect ș i oferă un mediu flexibil ș i consistent pentru
a adapta schimbările ș i a desfăș ura proiectul pentru a îndeplini obiectivele clientului. Faze SDLC
defineț i programul cheie ș i punctele de livrare care asigură o livrare corectă ș i la timp către client
în cadrul bugetului ș i altor constrângeri ș i cerinț e ale proiectului. SDLC cooperează cu controlul proiectului
ș i activităț ile de management, deoarece acestea trebuie să fie introduse în fiecare fază a SDLC.

Întrebare 3. Care sunt diferitele faze ale SDLC?

Răspuns.

Există 5 faze în Ciclu de Viaț ă al Dezvoltării Software-ului:

1. Cerinț e ș i analiză
2. Design
3. Programare
4. Testare
5. Întreț inere
Întrebarea 4. Ce este modelul SDLC? Care sunt cele mai cunoscute modele SDLC?

Răspuns.

Un model SDLC defineș te implementarea unei abordări asupra proiectului. Acesta defineș te diferitele
procesele ș i etapele care vor fi desfăș urate pe parcursul proiectului pentru a produce rezultatul dorit
Există o varietate de modele SDLC care există pentru a satisface diferite nevoi ș i
caracteristicile unui proiect. Unele sunt de natură iterativă (Prototipare), în timp ce altele sunt
secuenț ial (cascadă). Unele dintre modelele SDLC bine cunoscute sunt:

Waterfall Model
Model Iterativ
Modelul spiral
Modelul V
Model RAD
Model Agil

Ques 5. Descrie modelul de ciclu de viaț ă al dezvoltării software în stil waterfall.

Răspuns.

Modelul Waterfall este un model SDLC secvențial și non-iterativ care descrie fluxul etapelor în jos, una câte una.
Procesul nu începe o fază decât dacă faza anterioară este finalizată odată pentru totdeauna complet. Cascada
modelul constă din următoarele faze:
Colectarea cerințelor
Design
Implementare
Testare
Întreținere

Întrebare 6. Descrie pe scurt fazele din modelul în cascadă.

Răspuns. Colectarea cerinț elor: Toate cerinț ele sunt colectate ș i se efectuează o analiză pentru
sistem complet.
Proiectare: Diverse modele de proiectare sunt create pentru sistemul complet după faza de colectare a cerinț elor.
a fost finalizat și încheiat.
Implementare: Sistemul complet este implementat odată ce designul pentru sistem a fost finalizat.
Testare: Sistemul complet este testat după ce toate construcțiile și integrarea s-au finalizat.
Întreținere: Suportul post-implementare se desfășoară după implementarea sistemului.

Întrebare 7. Explicaț i punctele forte ale modelului de tip waterfall.

Forț ele modelului în cascadă sunt:

a) Nu este nevoie de planificare

b) Funcț ionează bine pentru proiecte mici cu cerinț e fixe ș i clare.

c) Cost mai mic deoarece suprastructura de planificare este mai mică

d) Livrarea cea mai rapidă a sistemului complet

Întrebare 8. Explicaț i slăbiciunile modelului de tip waterfall.

Răspuns.

Slăbiciunile modelului de tip waterfall sunt:

a) Este inflexibil
b) Accommodating changes is very hard
c) Cea mai lungă perioadă de livrare tangibilă. Clientul nu vede nimic altceva decât întregul produs
când este gata.
d) Inadecvat pentru proiecte mari ș i unde cerinț ele nu sunt clare.
Întrebare 9. Explicaț i când să folosiț i modelul în cascadă.

Răspuns. Modelul în cascadă ar trebui utilizat doar atunci când:

Cerinț ele sunt foarte clare ș i fixe.

Nu există cerinț e ambigue.
Resurse ample cu expertiza necesară sunt disponibile gratuit.
Clientul are o mare încredere în organizaț ie.
Organizaț ia are experienț ă în proiecte similare.
The project is short.

Întrebare 10. Descrie modelul de ciclu de viaț ă al dezvoltării software în formă de V.

Răspuns.

Modelul SDLC în formă de V este o extensie a modelului de tip apăfall. Apăfallul tipic se desfășoară liniar în jos,
în timp ce, în modelul în formă de V, fazele sunt îndreptate în sus după faza de codare pentru a forma forma de V. Acesta demonstrează
relația dintre fiecare fază a SDLC și faza sa respectivă de testare. Spre deosebire de modelul de tip waterfall, modelul în formă de V
include planificarea timpurie a testării.

Requirement analysis---------------------------------------Acceptance testing

Proiectarea sistemului------------------------------------Testarea sistemului
Design arhitectural -----------------------------Testare de integrare
Designul modulului----------------------------Testarea unității
Codare

Întrebare 11. Descrieț i pe scurt fazele modelului în formă de V.

Ans.

Phases in V-Shaped model:

Fazele de verificare sunt pe partea stângă a formei în V. Acestea constau în:

Analiza cerinț elor: Cerinț ele sunt colectate, iar analiza este efectuată pentru a înț elege
problemă ș i propune o soluț ie.
Proiectarea sistemului: Inginerii analizează cerinț ele adunate ș i propun modalităț i prin care sistemul poate
să fie creat sau construit din punct de vedere al fezabilităț ii.
Designul arhitecturii: Arhitectura sistemului este concepută din diverse module,
depicting their relationships and communication between them.
Designul modulului: Acesta este un design de nivel jos în care modulele sunt proiectate individual ș i într-un
mod detaliat.
Codare: Acesta este la baza modelului în formă de V. Proiectarea modulului este transformată în cod de către
dezvoltatori.
Fazele de validare sunt pe partea dreaptă a formei de V. Acesta constă în:
Testarea unităț ilor: Testarea prin analiza codului de către dezvoltatori pentru modulele lor independente se realizează.
Testarea integrării: Modulele independente sunt testate împreună pentru a valida interfaț a ș i a expune
erori în ele.
Testarea sistemului: Sistemul este testat în raport cu specificaț iile sistemului.
Testarea de acceptare de către utilizatori: Testarea este efectuată de utilizatorii finali pentru a valida cerinț ele
menț ionate în faza de cerinț e au fost îndeplinite de sistem sau nu înainte de a-l accepta pentru
production.
Întrebare 12. Explicaț i punctele forte ale modelului în formă de V.

Răspuns.

Punctele forte ale modelului în formă de V:

un model simplu ș i uș or de utilizat.

b) Fiecare fază are livrabile clare ș i fixe.
c) Ș anse mai mari de succes deoarece planificarea testării începe devreme în ciclul SDLC.
d) Cel mai rapid pentru proiectul în care cerinț ele sunt fixe ș i clar definite.

Întrebare 13. Explicaț i slăbiciunile modelului în formă de V.

Întrebare: Slăbiciunile modelului în formă de V:

a) Este inflexibil.
b) Schimbările în cerinț e sunt foarte greu de acomodate
c) Nu sunt disponibile prototipuri timpurii
d) Necesită resurse competente ample.
Întrebare 14. Explicaț i când să folosiț i modelul în formă de V.

Modelul în formă de V ar trebui folosit pentru proiecte mici până la medii unde cerinț ele
sunt definite ș i fixate clar. Modelul permite mai multă planificare pentru test decât modelul waterfall
dar face acomodarea schimbărilor mai dificilă decât alte modele. Modelul în formă de V ar trebui să
fie ales când sunt disponibile resurse tehnice ample cu expertiza tehnică necesară.
Deoarece nu sunt produse prototipuri, există un risc foarte mare implicat în satisfacerea clientului
aș teptările, prin urmare, încrederea clientului ar trebui să fie foarte mare pentru a alege V-
Abordarea modelului formatat.

Întrebare 15. Descrie modelul ciclului de viaț ă al dezvoltării software-ului prototip.

Modelul SDLC de prototip se bazează pe crearea unui prototip software complet

sistemul ș i apoi să-l îmbunătăț im ș i să-l revizuim continuu până când se construieș te un sistem complet acceptabil.

Întrebarea 16. Descrie pe scurt fazele din modelul de prototip.

Răspuns. Faze în modelul prototip:

Identifică câteva cerinț e pentru a începe: Obț ine o listă cu câteva cerinț e importante care definesc
nevoia pentru noul sistem, inclusiv informaț iile principale de intrare ș i ieș ire.
Dezvoltaț i un prototip iniț ial: Dezvoltaț i un prototip iniț ial de bază care are doar ecrane UI.
Revizuirea prototipului: Utilizatorii finali ș i IMM-urile lucrează ș i examinează prototipul ș i oferă
feedback for improvements/enhancements.
Revizuirea ș i îmbunătăț irea prototipului: Domeniul s-a schimbat pe baza feedback-ului de la utilizatori finali ș i
prototipul este îmbunătăț it ș i rafinat pentru a ț ine cont de feedback-ul utilizatorilor.

Întrebare 17. Explicaț i avantajele modelului prototip.

Răspuns.

Punctele forte ale modelului prototip sunt:

a) Câș tigă încrederea clienț ilor, deoarece dezvoltatorii ș i clienț ii sunt în sincron unul cu celălalt
aș teptări continuu.
b) Ideal pentru sistemele online unde este implicat un nivel ridicat de interacț iune om-computer.
c) Foarte flexibil, deoarece schimbările în cerinț e pot fi accommodate mult mai uș or cu
fiecare recenzie nouă ș i rafinarea.
d) Ajută atât dezvoltatorii, cât ș i utilizatorii să înț eleagă mai bine sistemul.
e) Software-ul construit prin prototipare necesită o formare minimă a utilizatorilor, deoarece utilizatorii sunt instruiț i folosind
prototipuri de la bun începutul proiectului.
f) Cerinț ele de integrare sunt foarte bine înț elese ș i canalele de desfăș urare sunt decise la
o etapă foarte timpurie

Întrebare 18. Explicaț i slăbiciunile modelului de prototip.

Răspuns.

Slăbiciunile modelului de prototip sunt:

a) Concentrarea pe prototip poate duce la confuzia dezvoltatorilor în înț elegerea ceea ce se doreș te de fapt.
sistem.
b) Utilizatorii finali devin confuzi, crezând că prototipul este sistemul complet
c) Dezvoltatorii ar putea înț elege greș it obiectivele utilizatorilor finali.
d) Dezvoltatorul s-ar putea implica prea mult în prototip ș i ar putea devia de la sistemul actual pe care
prototipul trebuie să fie convertit în.
e) Costisitor, deoarece prototipurile necesită mult efort ș i timp. Poate fi nevoie de multă muncă pentru a fi finalizată.
foarte puț in de muncă de realizat.
Întrebare 19. Explicaț i când să folosiț i modelul Prototype.

Modelul prototip ar trebui folosit atunci când sistemul dorit trebuie să aibă multe
interacț iune cu utilizatorii finali. De obicei, sistemele online, interfeț ele web au o cantitate foarte mare
de interacț iune cu utilizatorii finali, sunt cel mai potrivite pentru modelul Prototype. Ar putea dura o vreme pentru un
sistem care să fie construit pentru a permite uș urinț a utilizării ș i să necesite o instruire minimă pentru utilizatorul final.

Prototiparea asigură că utilizatorii finali lucrează constant cu sistemul ș i oferă un feedback

care este încorporat în prototip pentru a rezulta într-un sistem utilizabil. Ele sunt excelente pentru
proiectarea unor bune sisteme de interfaț ă om-computer.

Întrebare 20. Descrie ciclul de viaț ă al dezvoltării software-ului în dezvoltarea rapidă a aplicaț iilor (RAD)
model.

[Link] implică dezvoltarea iterativă împreună cu crearea prototipurilor. Foloseș te interacț iuni
utilizarea tehnicilor ș i prototipurilor pentru a defini clar cerinț ele utilizatorului ș i designul sistemului.
Tehnicile structurate sunt folosite pentru a crea modele iniț iale de design bazate pe inputul utilizatorului ș i
prototipurile sunt construite pe baza acestora. Utilizatorii finali ș i analiș tii folosesc prototipurile pentru a valida
ș i îmbunătăț eș te cerinț ele ș i modelele de design. Procesul durează până la un set final de specificaț ii tehnice
cerinț ele ș i modelele de design au fost create.

Întrebare 21. Descrieț i pe scurt fazele din modelul de dezvoltare rapidă a aplicaț iilor (RAD).

Răspuns.
Phases in RAD:
Modelarea afacerii: Fluxul de informații este identificat între diverse funcții de afaceri.
Modelarea datelor: Informațiile adunate din modelarea afacerii sunt folosite pentru a defini obiectele de date care sunt necesare pentru
afacere.
Modelarea proceselor: Obiectele de date definite în modelarea datelor sunt convertite pentru a realiza fluxul de informații de afaceri.
atingeți un anumit obiectiv de afaceri. Descrierile sunt identificate și create pentru CRUD-ul obiectelor de date.
Generarea aplicaț iilor: Instrumentele automate sunt utilizate pentru a transforma modelele de proces în cod ș i în sistemul actual.
Testare ș i rotire:Testează componentele noi ș i toate interfeț ele

Întrebare 22. Explicaț i punctele forte ale modelului de dezvoltare rapidă a aplicaț iilor (RAD).

Răspuns.

Strengths of RAD:

a) Timp de dezvoltare redus.

b) Creș te reutilizabilitatea componentelor
c) Modularizarea înaltă obț ine un sistem mai flexibil ș i mai uș or de întreț inut
d) Recenzii iniț iale rapide au loc.

e) Încurajează feedback-ul clienț ilor

f) Integrarea de la bun început rezolvă multe probleme de integrare.
g) Proprietarii de afaceri participă activ
Întrebare 23. Explicaț i slăbiciunile modelului de Dezvoltare Rapidă a Aplicatiilor (RAD).

Răspuns.

Weaknesses of RAD:
a) Depinde de performanț ele puternice ale echipei ș i ale indivizilor pentru identificarea cerinț elor de afaceri.
b) Doar sistemele care pot fi modularizate pot fi construite folosind RAD
c) Necesită dezvoltatori/designeri foarte bine pregătiț i.
d) Dependenț ă mare de abilităț ile de modelare
e) Inaplicabil pentru proiectele mai ieftine, deoarece costul modelării ș i generării automate a codului este
foarte ridicat pentru proiecte cu buget mai mic pentru a beneficia.

Întrebare 24. Explicaț i când să folosiț i modelul de dezvoltare rapidă a aplicaț iilor (RAD).

[Link] ar trebui utilizat atunci când există necesitatea de a crea un sistem care poate fi modularizat în 2-
3 months of time. It should be used if there’s high availability of designers for modeling and the
bugetul este suficient de mare pentru a acoperi costul acestora, împreună cu costul generării automate de cod
unelte. Modelul RAD SDLC ar trebui să fie ales doar dacă există resurse cu o cunoaș tere de afaceri înaltă.
disponibil ș i există o nevoie de a produce sistemul într-o perioadă scurtă de timp (2-3 luni).

Întrebare 25. Descrie modelul de ciclu de viaț ă al dezvoltării software-ului incremental.

Abordarea incrementală a SDLC sugerează construirea unui sistem parț ial mai degrabă decât
sistem complet ș i apoi adaugă mai multe funcț ionalităț i în acesta. Cerinț ele ș i caracteristicile sunt
prioritizat ș i categorisit ș i apoi implementat în etape, fiecare etapă bazată pe
modelul cascada. Procesul continuă până când sistemul complet este realizat.

Întrebare 26. Descrie pe scurt fazele modelului incremental.

Fazele modelului incremental sunt aceleaș i cu cele ale modelului în cascadă, adică cerinț e, design,
implementare, testare, întreț inere. Cu toate acestea, în loc să urmeze modelul waterfall o dată ș i pentru totdeauna
all linearly, incremental model takes a different approach. In this phases are repeated
incremental pe măsură ce valoarea de afaceri este livrată incremental de asemenea.
Pentru fiecare fază ș i increment, se urmează un model de tip waterfall. Modelul de tip waterfall este apoi
introduceț i într-un ciclu de creș teri împreună cu verificarea cerinț elor ș i designul.

Întrebare 27. Explică punctele forte ale modelului Incremental.

Răspuns.

Punctele forte ale modelului incremental sunt:

a) Dezvoltaț i întâi caracteristicile afacerilor cu risc ridicat

b) Fiecare increment oferă un produs operaț ional

c) Încrederea clientului este ridicată deoarece aceș tia validează fiecare increment ș i oferă feedback.
d) Cost iniț ial de livrare scăzut
e) Schimbările în cerinț e pot fi accommodate cu uș urinț ă.
f) Mai flexibil decât modelul cascade

Întrebare 28. Explicaț i slăbiciunile modelului incremental.

Răspuns. Punctele slabe ale modelului incremental sunt:
a) Necesită o planificare ș i un design bun.
b) Necesită o definiț ie clară ș i completă a sistemului complet înainte de a putea fi desfăcut.
ș i construit incremental.
Nevoile de integrare sunt foarte mari
d) Costul total este mai mare decât cascada.

Întrebare 29. Explicaț i când să folosiț i modelul incremental.

Modelul incremental ar trebui folosit doar când:

Cerinț ele sistemului complet sunt clar definite ș i înț elese.
Cerinț ele majore trebuie definite; cu toate acestea, unele detalii pot evolua în timp.
Este nevoie să aducem un produs pe piaț ă cât mai devreme.
O nouă tehnologie este folosită
Resursele cu abilităț ile necesare nu sunt disponibile
There are some high risk features and goals.

Întrebare 30. Descrie modelul de ciclu de viaț ă al dezvoltării software-ului spiral.

Modelul SDLC spiral combină componentele atât din design, cât ș i din prototip în etape. Este un
hibrid al modelului de cascada ș i modelului de prototipare. Ar trebui să se folosească modelul SDLC în spirală pentru proiecte mari ș i

proiecte scumpe.

Întrebare 31. Descrie pe scurt fazele din modelul spiral.

Răspuns.
Phases in spiral model:
a) Cerinț ele sistemului sunt identificate în detaliu.
b) Un design iniț ial este creat pentru noul sistem pe baza cerinț elor din faza anterioară.
Toate abordările fezabile ș i tehnice sunt identificate ș i analizate pentru a construi sistemul.
designul este realizat pe o scară mult mai largă ș i mai profundă pentru a identifica ș i a gestiona riscurile potenț iale în
sistemul.
c) Un prototip este creat, ilustrând câteva caracteristici ale sistemului.
d) Un al doilea prototip este creat folosind 4 paș i: Evaluarea primului prototip, definirea cerinț elor pentru
al doilea prototip, planificarea ș i proiectarea pentru al doilea prototip, construirea ș i testarea
al doilea prototip.
Întrebare 32. Explicaț i punctele forte ale modelului spiral.

Răspuns.

Punctele forte ale modelului spiral:

a) Identificarea timpurie a zonelor potenț iale de risc.

b) Clientul vede un prototip foarte devreme în SDLC.
c) Caracteristicile critice ș i riscante sunt construite mai întâi pentru a diminua riscurile ș i a clarifica cerinț ele.
d) Designul poate evolua prin iteraț ii.
e) Feedback-ul utilizatorilor ajută la menț inerea aș teptărilor lor.
f) Costul este evaluat frecvent, prin urmare o planificare mai bună.

Întrebare 33. Explicaț i slăbiciunile modelului spiral.

Răspuns. Punctele slabe ale modelului spiral sunt:
a) Nu este potrivit pentru proiecte mai mici sau cu buget redus, deoarece costul pentru identificarea riscurilor este ridicat.
b) Timpul petrecut pe riscuri, planificare ș i prototipare poate să nu fie la fel de eficient.
c) Este complex.
d) Spirala poate continua la nesfârș it.
e) Dificil de definit repere clare, care să permită SDLC-ului să treacă la următoarea fază.
f) Dezvoltatorii trebuie să aibă alte activităț i în timpul fazelor de non-dezvoltare.

Întrebare 34. Explicaț i când să folosiț i modelul spiral.

Răspuns.

Modelul spiral ar trebui folosit atunci când:

a) Prototipurile sunt aș teptate/necesare.

b) Proiecte mari ș i cu buget ridicat
c) Când evaluarea riscurilor este foarte critică
d) Cerinț ele nu sunt foarte clar definite.
e) Cerinț ele sunt vagi ș i chiar complexe
f) Organizaț ia nu are multă experienț ă în domeniu.
Este disponibil timp suficient.
Întrebare 35. Descrie modelul de ciclu de viaț ă al dezvoltării software-ului personalizat.

Răspuns. Nu există un model specific de SDLC care să poată fi folosit pentru toate tipurile de proiecte ș i situaț ii. Dacă
dacă niciunul dintre modelele populare SDLC nu se potriveș te pentru un proiect specific, atunci alegeț i modelul SDLC cel mai apropiat.
modelaț i ș i modificaț i-l conform nevoilor. Identificaț i cât de important este evaluarea riscurilor ș i folosiț i riscul spiralelor
metodologia de evaluare dacă este un proiect critic din punct de vedere al riscurilor. Proiectul ar trebui livrat în mici segmente,
ideal ar fi să combinăm modelul incremental cu modelul în formă de V. Trebuie să se acorde suficient timp în
alegerea modelului potrivit sau personalizarea unuia pentru a se potrivi unui proiect pentru succesul ș i eficienț a acestuia

finalizare.

Întrebare 36. Descrie importanț a selectării membrilor echipei cu un amestec de personalităț i.

tipuri pentru dezvoltarea software-ului.

Răspuns.
Alegerea sau construirea echipei potrivite este esenț ială pentru succesul oricărui proiect. Un proiect are nevoie de o varietate
a abilităț ilor ș i calităț ilor care nu sunt prezente în niciun individ. Cu toate acestea, ca o soluț ie alternativă, o echipă
ar trebui să fie construit din oameni cu o varietate de abilităț i pentru a îndeplini necesităț ile proiectului. Principalul avantaj
de a alege membri ai echipei cu un amestec de tipuri de personalitate este că oferă o gamă mai variată de
opinii despre un proiect sau orice element de acț iune specific din proiect, de exemplu: cerinț e, design,
dezvoltare, testare sau chiar implementare. Viziuni diferite permit un unghi mai larg asupra unei
problemă ș i soluț ie pentru minimizarea riscului de a omite cerinț ele sau de a le înț elege greș it.
Unele dintre trăsăturile de personalitate care sunt esenț iale pentru orice proiect sunt:

a) O persoană agresivă, ambiț ioasă, contrară, o personalitate calmă, răbdătoare ș i mai relaxată
b) Persoană care îș i asumă riscuri, contrariană, o personalitate precaută

c) Personalitate strategică, contrară, analitică

g) Gândirea laterală
Situaț ii diferite într-un proiect sunt gestionate mai bine de diferite tipuri de personalitate ș i, prin urmare, o
amestecul perfect de tipuri de personalitate este esenț ial pentru ca proiectul să se finalizeze cu succes.
Întrebare 37. Descrie etapele dezvoltării echipei în SDLC.

Raspuns.

Cele 4 etape ale construirii unei echipe sunt:

Formare: Membrii echipei sunt informaț i ce se aș teaptă de la ei ș i unde se încadrează.

echipa. Echipa este ghidată folosind linii directoare de operare ș i comunicarea în interior.

Furtuna: În această fază, membri echipei arată o oarecare rezistenț ă ș i frustrări încercând să lucreze
împreună. Vor exista invidii ș i ciocniri de ego ș i managerul echipei trebuie să acț ioneze ca un
arbitru sau antrenor.
Norming:In this phase the team has learnt to function as a whole. Team members find their
moduri consistente de lucru ș i îș i reț in ideile pentru a evita problemele ș i conflictele. Echipa
managerul ghidează echipa să nu se reț ină prin creș terea responsabilităț ilor ș i
presiuni.
Executare:În această fază, echipa a învăț at să îș i îndeplinească rolul ca un întreg, să aibă ș i să rezolve
conflicte, asumarea de riscuri, făcând ajustări sau compromisuri ș i acț ionând activ pentru a face faț ă diverselor
provocări.

Întrebare 38. Care este diferenț a dintre un model iterativ ș i modelul Waterfall?

Modelul Waterfall este un model bazat pe flux, în care parcurgem fiecare fază o dată ș i nu putem
reveni la acea fază din nou. Cel mai important dezavantaj este că dacă există vreo schimbare în
cerinț e, nu putem face nicio modificare în secț iunea cerinț elor. Modelul Iterativ este
asemănător modelului în cascadă, dar aici putem reveni întotdeauna la fazele anterioare
ș i faceț i modificările în consecinț ă.

Întrebare 39. Explicaț i diferenț a dintre SDLC ș i STLC?

[Link] este un model de ciclu de viaț ă al dezvoltării software care este utilizat pentru gestionarea proiectelor.
ș i implică procese de la analiza fezabilităț ii până la întreț inerea celor finalizate
aplicaț ie. STLC este Ciclu de viaț ă al testării software ș i SDLC lucrează strâns împreună ș i sunt aproape
inseparabile în cadrul unor activităț i. Cu toate acestea, etapele sunt foarte diferite în cadrul sdlc ș i
stlc

Întrebarea 40. Ce sunt cerinț ele funcț ionale?

Ans. Cerinț a funcț ională este un document care conț ine ce trebuie să facă un anumit sistem pentru a
atingerea unui anumit obiectiv specific. Această sarcină se desfăș oară în timpul etapei preliminare a SDLC.

Întrebare 41. Ce sunt cerinț ele non-funcț ionale?

Fără non-funcț ional, un software nu va funcț iona niciodată sau va avea informaț ii vitale lipsă.
rezultatul său. Timpul de răspuns, securitatea, fiabilitatea, acurateț ea, capacitatea ș i disponibilitatea sunt exemple
de cerinț e non funcț ionale pentru un proces de dezvoltare software. Cerinț e non funcț ionale
decide cum va funcț iona programul sau software-ul în viitor.
Întrebare 42. Care este diferenț a între modelul Incremental ș i modelul Spiral?

Răspuns. Nu există o mare diferenț ă între aceste două modele SDLC. Modelul SDLC spiral include...
natura iterativă a modelului de prototipare ș i natura liniară a modelului de tip cascade.
abordarea este ideală pentru dezvoltarea software-ului care apare în diverse versiuni.

Întrebare 43. Oferiț i câteva exemple practice din viaț a reală ale Modelului Spiral.

Răspuns. Cele mai populare exemple din viaț a reală pentru modelul Spiral al SDLC sunt sistemele de operare Microsoft Windows.

Sistem, Visual Studio Manager, Adobe Photoshop, WordPress CMS ș i multe altele.

Întrebare 44. De ce este Agile atât de popular?

Metodologia Agile este mult prea avansată ș i complexă comparativ cu modelul simplu Waterfall.
Fezabilitatea agilităț ii de a remodela întreaga structură de dezvoltare pentru a se adapta la cea mai eficientă
rezultatul este ceea ce face Agile alegerea numărul 1 pentru dezvoltatori astăzi.

Întrebare 45. Pot construi un proiect software fără modele SDLC?

Desigur. Nu există cerinț e stricte pentru un dezvoltator de a implementa orice SDLC.

model pentru dezvoltarea unui proiect software. Abilitatea de a simplifica proiectul în module ș i
stabilirea progresiei corecte pentru finalizare este singurul motiv pentru care modelele SDLC ș i
metodologia a fost concepută în primul rând. Poț i să lucrezi fără ele, dar...
provocările vor fi mai mari ș i nu va exista un proces specific pentru a-ț i organiza munca ca un
întreg.